为何文件系统采用独立块大小而非硬盘块大小？如何与块设备通信？

首先先明确两个概念的差异：硬盘自带的块（通常指机械盘物理扇区、SSD闪存页）是硬件层面定义的最小读写单位，而文件系统块是文件系统层面的最小数据分配单位，两者定位完全不同，文件系统单独设置块大小的原因主要有三点：

• 灵活适配不同业务场景的性能需求：如果是小文件密集场景（比如存站点缩略图、小程序包），用更小的文件系统块（比如1KB、2KB）可以大幅降低内部碎片，提升存储空间利用率；如果是大文件场景（比如存影视资源、系统备份镜像），用更大的块（比如8KB、32KB）可以减少元数据记录量，提升连续读写性能。如果直接绑死硬件自带的块大小，就没法针对不同场景做优化。
• 屏蔽底层硬件差异，保证兼容性：不同块设备的原生块大小差异极大，从老机械盘的512B、新消费级硬盘的4KB，到RAID阵列的64KB/128KB条带单元，再到企业级SSD的32KB/64KB擦除块，如果文件系统直接使用硬件原生块，同一份文件系统镜像就无法在不同硬件之间迁移兼容，也没办法在逻辑卷、加密层这类虚拟块设备上运行。
• 平衡元数据与数据的存储效率：文件系统除了用户数据，还要存储inode、块位图、分区表这类元数据。如果块太小，元数据需要记录的块数量会暴涨，既占用额外存储空间，也会拖慢文件寻址速度；如果块太大又会出现严重的空间碎片问题，独立设置块大小可以让文件系统在两者之间找到最优平衡。

整体交互流程可以简化为以下几个步骤：

• 上层应用通过read()/write()这类系统调用发起文件读写请求，文件系统先将请求转换为对自身内部逻辑块号的操作。
• 文件系统首先查询系统页缓存（Page Cache），如果请求的数据已经在缓存中，就直接返回结果/修改缓存内容，无需访问实际硬件，脏缓存会由操作系统后续批量同步到磁盘。
• 如果缓存未命中，文件系统会把自身的逻辑块号映射为块设备通用的逻辑扇区号（LBA），再把IO请求提交给操作系统的块IO调度层。
• 块IO调度层会对多个IO请求做合并、排序、优先级调度，减少磁盘寻道开销，再把整理后的请求下发给对应块设备的驱动程序。
• 驱动程序和硬件完成实际的读写操作后，再把结果逐层回传给文件系统，最终返回给上层应用。

内容的提问来源于stack exchange，提问作者Dmitriy