1. 文件系统基础：理解文件块大小、扇区与簇的概念
各位好，我是老张。今天咱们聊聊文件系统最底层的那点事——块、扇区、簇。你别看这些概念基础，我敢说，很多做了三五年开发的人，也未必真搞懂了它们怎么影响读写性能。
说白了，文件系统就是个“仓库管理员”。它得决定：你的数据怎么存、存哪儿、一次搬多少。而这些决策，全绕不开三个核心单位：扇区、块、簇。
1.1 扇区：硬盘的“最小原子”
扇区是物理硬盘能读写的最小单位。传统机械硬盘一个扇区 512 字节，现在新硬盘基本都是 4K 扇区（4096 字节）。
为什么会有这个变化？我当年做存储优化时遇到过一个问题：一个 512 字节的日志文件，写入时却要读整个 4K 扇区再写回去。这叫“读-改-写”操作，性能损耗非常大。后来换成 4K 扇区的硬盘，同样的小文件写入，效率直接翻倍。
关键点：操作系统不能直接操作扇区，它得通过文件系统来间接管理。扇区是物理层的最小单位，文件系统层的最小单位是“块”。
1.2 块：文件系统的“逻辑砖块”
块是文件系统读写的最小逻辑单位。它的大小通常是扇区的整数倍，比如 512 字节、1K、2K、4K。
你想想看，如果块太小，文件系统就得频繁访问硬盘，元数据开销巨大。如果块太大，小文件又会浪费空间。我见过一个极端案例：有人把块大小设成 64K，然后存了一堆 1K 的配置文件，结果磁盘利用率不到 2%。
| 块大小 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 512B - 1K | 小文件密集（日志、配置） | 空间利用率高 | 元数据多，大文件读写慢 |
| 4K | 通用场景（数据库、普通文件） | 平衡空间与性能 | 小文件有碎片 |
| 16K - 64K | 大文件（视频、备份、镜像） | 顺序读写极快 | 小文件浪费空间 |
我的习惯：做数据库服务器时，我一般用 8K 或 16K 的块大小。因为数据库的页大小通常是 8K，块对齐后能避免“跨块读”的额外开销。
1.3 簇：文件系统的“分配单位”
簇是文件系统分配磁盘空间的最小单位。一个簇包含一个或多个连续的块。在 Windows 的 NTFS 里，簇也叫“分配单元”。
嗯，这里要注意：簇和块经常被混用，但严格来说，块是逻辑读写单位，簇是空间分配单位。比如你创建一个 1 字节的文件，它至少占用一个簇的空间。如果簇大小是 4K，那这个文件就白白浪费了 4095 字节。
我曾经帮一个客户优化文件服务器，发现他们用默认的 4K 簇存了上百万个 2-3K 的小文件。我建议改成 2K 簇，结果磁盘空间节省了 40%，读写性能反而提升了 15%。为什么？因为簇小了，碎片少了，文件系统寻址更快了。
避坑指南：我曾经在格式化一个 10TB 的备份盘时，用了默认的 4K 簇。结果存大文件时，文件系统要管理上亿个簇，元数据表膨胀到几十 GB，每次读写都卡。后来改成 64K 簇，问题立刻解决。记住：大分区配大簇，小文件多配小簇。
1.4 它们如何影响读写性能？
这三者的关系，我用一张图来展示：
从这张图你能看到，数据从应用层到硬盘，要经过三层封装。每一层的单位大小不匹配，就会产生性能损耗。最典型的就是“4K 对齐”问题——如果文件系统的块大小和硬盘的扇区大小不对齐，每次写入都要先读整个扇区，修改后再写回去，性能直接腰斩。
1.5 实战：如何选择合适的块/簇大小？
我个人的经验是，没有“万能”的大小，只有“适合”的大小。给你几个参考原则：
- 数据库服务器：块大小 = 数据库页大小（通常是 8K），簇大小 = 块大小。这样能避免跨页读写的额外开销。
- 文件服务器（小文件多）：簇大小 2K-4K。空间利用率高，碎片少。
- 视频/备份服务器（大文件多）：簇大小 64K-128K。顺序读写性能最大化，元数据开销最小。
- 虚拟机磁盘镜像：簇大小 4K-8K。兼顾随机读写和顺序读写。
一句话总结：扇区是物理限制，块是逻辑读写单位，簇是空间分配单位。性能调优的本质，就是让这三者对齐，同时根据文件大小分布选择合适的簇大小。
好了，这一章的基础概念就讲到这里。记住这些底层原理，后面我们讲文件大小调整和读写效率提升时，你就能理解为什么某些操作会快、某些操作会慢了。