一次关于文件系统簇大小、Finder 显示逻辑和“停车位”理论的探究后附实测截图一、现象两个文件夹两种“灵异”结果最近整理备份时我发现了两个令人费解的现象。我把电脑里的文件夹拷贝到外接备份盘文件内容一字未改但右键点击“显示简介”时磁盘占用却出现了截然不同的两种情况文件夹系统盘 (Macintosh HD)备份盘 (bak_Licw)差异data53.5万个项目405.63 GB 数据占用407.13 GB405.63 GB 数据占用509.29 GB相差 102.16 GBshuhuigao8.9万个项目1.697 TB 数据占用1.7 TB1.697 TB 数据占用1.7 TB肉眼看不出差异同样的操作同样的“未修改”为什么一个差出 100 多 G另一个却完全一样背后到底是谁在搞鬼二、推测存储最小单位-簇-类比“停车位”硬盘存文件不是像倒水一样无缝填充而是像停车位。硬盘的最小存储单元叫做“簇”又称分配单元/块。无论文件本身多小比如 1KB只要它存在就必须占用一个完整的簇文件占不满簇的尾部空间就白白浪费了。基于此我提出两个推论推论 A如果一个文件夹里全是几 KB 的小文件拷贝到大簇硬盘上每个文件都会浪费几百 KB 的“空地”。文件数量越多浪费越恐怖 → 这解释了data为什么差 100GB。推论 B如果文件夹里全是几十 MB 甚至 GB 级的大文件簇的“零头浪费”只体现在最后一个簇上占比极小肉眼完全看不出来 → 这解释了shuhuigao为什么显示相同。理论归理论必须动手验证。三、动手验证3 个实验实验环境MacBook Pro系统盘 APFS外接盘为 8TB 移动硬盘ExFAT 格式。验证①先查“簇大小”——拿到决定性物证在终端用diskutil info分别查看两个盘的分配单元大小bashdiskutil info /dev/disk3s5 | grep Allocation Block Size diskutil info /dev/disk5s2 | grep Allocation Block Size实测结果磁盘簇大小系统盘 (Macintosh HD)4 KB(4096 Bytes)备份盘 (bak_Licw)256 KB(262144 Bytes)结论备份盘的“车位”是系统盘的64 倍。这意味着同样一个 1KB 的小文件在系统盘只浪费 3KB在备份盘却要浪费 255KB。验证②复现“100G 差异”——海量小文件实验操作在桌面生成 1 万个 1KB 的假文件模拟代码缓存、缩略图分别拷贝到系统盘和备份盘观察磁盘占用。bashmkdir ~/Desktop/lab_small cd ~/Desktop/lab_small for i in {1..10000}; do dd if/dev/zero ofsmall_$i.txt bs1K count1; done cp -r ~/Desktop/lab_small /Volumes/bak_Licw/ du -sh ~/Desktop/lab_small du -sh /Volumes/bak_Licw/lab_small实测结果位置逻辑大小磁盘占用系统盘4KB 簇10 MB39 MB备份盘256KB 簇10 MB2.4 GB结论同样 10MB 的数据在大簇硬盘上膨胀了60 倍放大到出问题的 53 万个文件差出 100GB 完全符合数学预期。数学验算1万个文件 × 256KB 2.56GB显示为 2.4GB完全吻合你的data文件夹53.5万文件 × 平均浪费 ~200KB ≈107GB与实际 102GB 差异误差极小验证③复现“显示相同”——少量大文件实验操作生成 10 个 100MB 的大文件模拟视频、PSD重复上述拷贝和观察。bashmkdir ~/Desktop/lab_big cd ~/Desktop/lab_big for i in {1..10}; do dd if/dev/zero ofbig_$i.dat bs1M count100; done cp -r ~/Desktop/lab_big /Volumes/bak_Licw/ du -sh ~/Desktop/lab_big du -sh /Volumes/bak_Licw/lab_big实测结果位置逻辑大小磁盘占用系统盘4KB 簇1 GB1.0 GB备份盘256KB 簇1 GB1.0 GB结论大文件的体积远超单个簇簇浪费占比不足 0.01%所以在 GB 级别显示时被彻底“抹平”了。这正是shuhuigao文件夹的真相。数学验算理论最大浪费10个文件 × 256KB 2.56MB占 1GB 总量的比例2.56MB ÷ 1024MB ≈0.25%在 Finder 显示一位小数时1.000 GB和1.003 GB都显示为1.0 GB四、结论为什么一个差 100G一个看不出差通过以上实验可以铁定地下结论文件内容逻辑字节数没变但拷贝到不同格式的硬盘后“磁盘占用”出现巨大差异100% 由“簇大小”决定。文件夹项目数平均文件大小簇浪费占比最终表现data534,917~0.76 MB极高海量小文件导致尾部浪费严重差异102 GB肉眼可见shuhuigao89,380~19 MB极低 1%大文件尾部浪费可忽略差异被四舍五入到1.7 TB抹平用数学验算一下shuhuigao的理论最大浪费89,380 个文件 × 256KB ≈ 22.8 GB占总量1,697 GB的1.3%。在 Finder 显示一位小数时1.697 TB和1.720 TB都会显示为1.7 TB所以你看不出差异。五、延伸思考簇大小能改吗改了会怎样簇大小可以设定吗可以但有限制。APFS系统盘簇大小固定为4KB无法手动更改。这是苹果为 SSD 深度优化的设计。ExFAT备份盘允许在格式化时设定簇大小。你的备份盘之所以是 256KB是系统在格式化 8TB 大容量硬盘时自动选择的默认值。如果想在格式化 ExFAT 时指定簇大小可以用终端命令bashsudo newfs_exfat -b 4096 /dev/disk5s2 # 设为 4KB把簇改小有什么好处和坏处好处极大节省空间尤其对于海量小文件的场景。量化对比基于实测数据1万个1KB文件4KB簇下占39MB256KB簇下占2.4GB空间节省率(2.4GB - 39MB) / 2.4GB ≈ 98.4%坏处读写性能下降尤其对于大文件。场景大簇256KB小簇4KB大文件连续读写视频、PSD快减少碎片管理开销慢需管理更多碎片小文件随机读写代码、照片慢每次读写一个超大块快浪费少操作灵活量化数据参考在 NTFS 格式下将簇从 32KB 增至 128KB连续写入 5GB 视频文件的性能可提升约12% - 18%。但 128KB 簇相比 4KB 簇小文件随机写入性能可能下降约18%。如何选择使用场景推荐簇大小理由存放大文件视频素材、系统备份、游戏镜像256KB 或更大空间浪费占比小读写性能更优存放海量小文件代码仓库、网站资源、照片缓存4KB空间利用率极高避免几十甚至上百 GB 的浪费混合使用日常通用默认 4KB空间与性能的最稳妥平衡点六、实用建议不再焦虑以后看到备份盘“莫名多占”空间你知道这是物理规律不是病毒或损坏。备份策略优化如果经常备份含海量小文件的项目如node_modules、Python 虚拟环境、照片缩略图库要么格式化备份盘为 APFS要么先打成压缩包再拷贝可以轻松省出几十甚至几百 GB。附实验验证截图以下截图来自笔者在 MacBook Pro 上的真实实验所有数据均可复现。实验环境系统盘Macintosh HDAPFS默认簇大小 4KB备份盘bak_LicwExFAT默认簇大小 256KB图一站式实验脚本的完整终端输出截图解读实验项目系统盘4KB簇备份盘256KB簇结论簇大小4096 Bytes262144 Bytes备份盘“车位”是系统盘的 64 倍实验一1万个小文件逻辑大小 10MB39 MB2.4 GB膨胀约 60 倍实验二10个大文件逻辑大小 1GB1.0 GB1.0 GB肉眼完全看不出差异实验结论截图清晰展示了“海量小文件”在大簇硬盘上空间急剧膨胀而“少量大文件”则不受影响。这正是data文件夹差 100GB、而shuhuigao文件夹显示相同的原因。
一次关于文件系统簇大小、Finder 显示逻辑和“停车位”理论的探究后附实测截图一、现象两个文件夹两种“灵异”结果最近整理备份时我发现了两个令人费解的现象。我把电脑里的文件夹拷贝到外接备份盘文件内容一字未改但右键点击“显示简介”时磁盘占用却出现了截然不同的两种情况文件夹系统盘 (Macintosh HD)备份盘 (bak_Licw)差异data53.5万个项目405.63 GB 数据占用407.13 GB405.63 GB 数据占用509.29 GB相差 102.16 GBshuhuigao8.9万个项目1.697 TB 数据占用1.7 TB1.697 TB 数据占用1.7 TB肉眼看不出差异同样的操作同样的“未修改”为什么一个差出 100 多 G另一个却完全一样背后到底是谁在搞鬼二、推测存储最小单位-簇-类比“停车位”硬盘存文件不是像倒水一样无缝填充而是像停车位。硬盘的最小存储单元叫做“簇”又称分配单元/块。无论文件本身多小比如 1KB只要它存在就必须占用一个完整的簇文件占不满簇的尾部空间就白白浪费了。基于此我提出两个推论推论 A如果一个文件夹里全是几 KB 的小文件拷贝到大簇硬盘上每个文件都会浪费几百 KB 的“空地”。文件数量越多浪费越恐怖 → 这解释了data为什么差 100GB。推论 B如果文件夹里全是几十 MB 甚至 GB 级的大文件簇的“零头浪费”只体现在最后一个簇上占比极小肉眼完全看不出来 → 这解释了shuhuigao为什么显示相同。理论归理论必须动手验证。三、动手验证3 个实验实验环境MacBook Pro系统盘 APFS外接盘为 8TB 移动硬盘ExFAT 格式。验证①先查“簇大小”——拿到决定性物证在终端用diskutil info分别查看两个盘的分配单元大小bashdiskutil info /dev/disk3s5 | grep Allocation Block Size diskutil info /dev/disk5s2 | grep Allocation Block Size实测结果磁盘簇大小系统盘 (Macintosh HD)4 KB(4096 Bytes)备份盘 (bak_Licw)256 KB(262144 Bytes)结论备份盘的“车位”是系统盘的64 倍。这意味着同样一个 1KB 的小文件在系统盘只浪费 3KB在备份盘却要浪费 255KB。验证②复现“100G 差异”——海量小文件实验操作在桌面生成 1 万个 1KB 的假文件模拟代码缓存、缩略图分别拷贝到系统盘和备份盘观察磁盘占用。bashmkdir ~/Desktop/lab_small cd ~/Desktop/lab_small for i in {1..10000}; do dd if/dev/zero ofsmall_$i.txt bs1K count1; done cp -r ~/Desktop/lab_small /Volumes/bak_Licw/ du -sh ~/Desktop/lab_small du -sh /Volumes/bak_Licw/lab_small实测结果位置逻辑大小磁盘占用系统盘4KB 簇10 MB39 MB备份盘256KB 簇10 MB2.4 GB结论同样 10MB 的数据在大簇硬盘上膨胀了60 倍放大到出问题的 53 万个文件差出 100GB 完全符合数学预期。数学验算1万个文件 × 256KB 2.56GB显示为 2.4GB完全吻合你的data文件夹53.5万文件 × 平均浪费 ~200KB ≈107GB与实际 102GB 差异误差极小验证③复现“显示相同”——少量大文件实验操作生成 10 个 100MB 的大文件模拟视频、PSD重复上述拷贝和观察。bashmkdir ~/Desktop/lab_big cd ~/Desktop/lab_big for i in {1..10}; do dd if/dev/zero ofbig_$i.dat bs1M count100; done cp -r ~/Desktop/lab_big /Volumes/bak_Licw/ du -sh ~/Desktop/lab_big du -sh /Volumes/bak_Licw/lab_big实测结果位置逻辑大小磁盘占用系统盘4KB 簇1 GB1.0 GB备份盘256KB 簇1 GB1.0 GB结论大文件的体积远超单个簇簇浪费占比不足 0.01%所以在 GB 级别显示时被彻底“抹平”了。这正是shuhuigao文件夹的真相。数学验算理论最大浪费10个文件 × 256KB 2.56MB占 1GB 总量的比例2.56MB ÷ 1024MB ≈0.25%在 Finder 显示一位小数时1.000 GB和1.003 GB都显示为1.0 GB四、结论为什么一个差 100G一个看不出差通过以上实验可以铁定地下结论文件内容逻辑字节数没变但拷贝到不同格式的硬盘后“磁盘占用”出现巨大差异100% 由“簇大小”决定。文件夹项目数平均文件大小簇浪费占比最终表现data534,917~0.76 MB极高海量小文件导致尾部浪费严重差异102 GB肉眼可见shuhuigao89,380~19 MB极低 1%大文件尾部浪费可忽略差异被四舍五入到1.7 TB抹平用数学验算一下shuhuigao的理论最大浪费89,380 个文件 × 256KB ≈ 22.8 GB占总量1,697 GB的1.3%。在 Finder 显示一位小数时1.697 TB和1.720 TB都会显示为1.7 TB所以你看不出差异。五、延伸思考簇大小能改吗改了会怎样簇大小可以设定吗可以但有限制。APFS系统盘簇大小固定为4KB无法手动更改。这是苹果为 SSD 深度优化的设计。ExFAT备份盘允许在格式化时设定簇大小。你的备份盘之所以是 256KB是系统在格式化 8TB 大容量硬盘时自动选择的默认值。如果想在格式化 ExFAT 时指定簇大小可以用终端命令bashsudo newfs_exfat -b 4096 /dev/disk5s2 # 设为 4KB把簇改小有什么好处和坏处好处极大节省空间尤其对于海量小文件的场景。量化对比基于实测数据1万个1KB文件4KB簇下占39MB256KB簇下占2.4GB空间节省率(2.4GB - 39MB) / 2.4GB ≈ 98.4%坏处读写性能下降尤其对于大文件。场景大簇256KB小簇4KB大文件连续读写视频、PSD快减少碎片管理开销慢需管理更多碎片小文件随机读写代码、照片慢每次读写一个超大块快浪费少操作灵活量化数据参考在 NTFS 格式下将簇从 32KB 增至 128KB连续写入 5GB 视频文件的性能可提升约12% - 18%。但 128KB 簇相比 4KB 簇小文件随机写入性能可能下降约18%。如何选择使用场景推荐簇大小理由存放大文件视频素材、系统备份、游戏镜像256KB 或更大空间浪费占比小读写性能更优存放海量小文件代码仓库、网站资源、照片缓存4KB空间利用率极高避免几十甚至上百 GB 的浪费混合使用日常通用默认 4KB空间与性能的最稳妥平衡点六、实用建议不再焦虑以后看到备份盘“莫名多占”空间你知道这是物理规律不是病毒或损坏。备份策略优化如果经常备份含海量小文件的项目如node_modules、Python 虚拟环境、照片缩略图库要么格式化备份盘为 APFS要么先打成压缩包再拷贝可以轻松省出几十甚至几百 GB。附实验验证截图以下截图来自笔者在 MacBook Pro 上的真实实验所有数据均可复现。实验环境系统盘Macintosh HDAPFS默认簇大小 4KB备份盘bak_LicwExFAT默认簇大小 256KB图一站式实验脚本的完整终端输出截图解读实验项目系统盘4KB簇备份盘256KB簇结论簇大小4096 Bytes262144 Bytes备份盘“车位”是系统盘的 64 倍实验一1万个小文件逻辑大小 10MB39 MB2.4 GB膨胀约 60 倍实验二10个大文件逻辑大小 1GB1.0 GB1.0 GB肉眼完全看不出差异实验结论截图清晰展示了“海量小文件”在大簇硬盘上空间急剧膨胀而“少量大文件”则不受影响。这正是data文件夹差 100GB、而shuhuigao文件夹显示相同的原因。
-详解JSON：轻量级数据交换格式)
-本地存储实战：待办事项网页的开发)
