1. 两个数字背后的两套算法前阵子帮朋友处理一个特别典型的状况他把 iPhone 备份迁到一块 2TB 的 PSSD 上Finder 里看整个 Backup 目录是 38.6 GB可硬盘的可用空间却实实在在掉了一大截。切到 Windows 上一看属性面板同一堆文件大小 38.6 GB占用空间 87.2 GB。差了一倍还多。他第一反应是硬盘虚标第二反应是中招了第三反应是准备把盘退掉。其实都不是。这个问题在 PSSDPortable SSD移动固态硬盘上出现的频率远高于普通机械移动盘因为现在的 PSSD 动辄 1TB、2TB、4TB出厂预格式化的文件系统基本都是 exFAT而 exFAT 在大容量卷上的默认分配单元也就是大家常说的簇能大到 128KB。128KB 什么概念一个 800 字节的.mdinfo文件在地上占一格,但格子的面积是 128KB。你有 20 万个这样的文件那就是 25.6 GB 的地皮而它们本身的内容加起来才 160 MB。所以这篇文章要解决的问题很具体为什么文件大小和占用空间会差这么多差在哪怎么定位怎么改。适合谁看把 iPhone 备份、照片图库、代码仓库、虚拟机镜像往 PSSD 上搬过的人给 Mac、Windows、Linux 三台机器共用一块移动硬盘的人以及所有看到占用空间这个数字心里发毛、但又不想瞎折腾的人。我会把计算过程、几个平台的排查命令、格式化时怎么选参数全部写清楚你照着抄就行。1.1 文件大小是内容的长度占用空间是分配的长度这两个数字的来源完全不同理解这一点后面所有现象都能自己推出来。**文件大小Size**是文件内容的字节数。一个文件写了 800 字节就是 800 字节这是逻辑上的长度由文件系统记录在元数据里。你在任何系统上看到的大小本质上都是这个数字。**占用空间Size on disk是文件在磁盘上真正占掉的物理空间。文件系统不会按字节给你分配空间它按簇Cluster也叫分配单元 Allocation Unit**分配。簇是文件系统能管理的最小单位一个文件必须占用整数个簇哪怕它只有 1 个字节。用图书馆打个比方书架上的格子是固定尺寸的书可以薄可以厚但你不能把两本书塞进同一个格子也不能把一本书拆开塞进两个格子。一本 20 页的小册子放进一个能装 2000 页的大格子里格子还是被占满了剩下的 1980 页空间就这么空着别的书进不来。这就是内部碎片Internal Fragmentation。公式写出来很直白单个文件占用的簇数 ⌈文件大小 ÷ 簇大小⌉向上取整大小 0 的文件不占簇单个文件的占用空间 占用簇数 × 簇大小单个文件的浪费 占用空间 − 文件大小当文件远小于簇时浪费就约等于一整个簇。这是最要命的情况也是 PSSD 上的主战场。1.2 算一笔账10 万个小文件能凭空吃掉 12 GB空谈没感觉直接算。假设你的 PSSD 是 exFAT2TB 容量Windows 默认格式化出来簇大小 128KB131072 字节。盘上有一个 iPhone 备份目录里面有 10 万个文件平均每个文件 4KB。逻辑大小100000 × 4KB 400 MB每个文件占用簇数⌈4096 ÷ 131072⌉ 1 簇每个文件占用空间128KB总占用空间100000 × 128KB ≈ 12.2 GB按 1 GB 1024 MB 计实际内容 400 MB占用空间 12.2 GB多出来的 11.8 GB 全是格子没装满的部分。倍数关系是 32 倍。换成不同的簇大小同一批文件的差距是这样簇大小单个 4KB 文件占用10 万个文件总占用相对实际内容4 KB4 KB400 MB1.0 倍16 KB16 KB1.6 GB4 倍32 KB32 KB3.2 GB8 倍64 KB64 KB6.4 GB16 倍128 KB128 KB12.8 GB32 倍这张表是整篇文章的核心。你可以看到簇大小每翻一倍小文件密集目录的占用空间就翻一倍而且这个关系是线性的、可预测的不是玄学。当文件大小在簇大小范围内随机分布时平均浪费大约是半个簇。所以还有个快速估算公式预估浪费空间 ≈ 文件数量 × 簇大小 ÷ 2这个公式在文件数量上万的目录里估出来的值相当准用来判断我这块盘是不是有救足够了。1.3 顺便澄清三个容易混淆的概念既然聊到大小和限制有几个词经常被搅在一起这里一次性切开。第一存储层的簇浪费和应用层的上传限制是两回事。比如服务端配置里把max-file-size设成 10MB那是限制单次上传的请求体大小跟文件在磁盘上占多少簇没有半毛钱关系。同样某些反向代理里配置的请求体上限也是应用层的事。这些限制影响的是能不能传上去不影响传上去之后占多少地。第二逻辑大小加起来对不上盘的已用空间还有很多别的来源。Windows 上的分页文件、休眠文件默认是隐藏且受保护的系统文件资源管理器里看不见但它们实实在在占着几十 GB。还有$RECYCLE.BIN回收站、System Volume Information卷影副本、NTFS 的 MFT主文件表通常会预留卷容量的 12.5% 左右、exFAT 的 FAT 表。这些加起来能解释掉一部分差额但解释不了大小 38GB、占用 87GB这种量级的差异那种量级的基本都是簇浪费。第三文件系统的元数据开销在大容量盘上不可忽略。exFAT 的 FAT 表大小 簇数量 × 4 字节。2TB 卷用 128KB 簇簇数量约 1638 万FAT 表约 65MB如果强行用 4KB 簇簇数量变成 5.37 亿FAT 表要 2.1GB 左右。这也是为什么大容量盘不建议用极小簇的原因之一后文会展开。2. 为什么偏偏 PSSD 上这个问题最扎眼同样的文件放在 Mac 内置盘上没感觉放在这块 PSSD 上就膨胀了这不是错觉是三个因素叠加的结果。搞清楚叠加的机制你才能决定到底是忍着、还是重新格式化、还是换文件系统。2.1 大容量卷加 exFAT默认簇大小被顶到天花板绝大多数 PSSD 出厂就是 exFAT因为它是目前唯一在 Windows、macOS、Linux 上都能免驱读写的通用方案。但 exFAT 的默认簇大小是跟着卷容量走的容量越大默认值越高。微软官方给出的默认值是卷容量exFAT 默认簇NTFS 默认簇FAT32 默认簇≤ 256 MB4 KB4 KB512 B256 MB – 32 GB32 KB4 KB4 KB – 16 KB32 GB – 256 GB128 KB4 KB32 KB256 GB – 2 TB128 KB4 KB32 KB2 TB – 16 TB128 KB4 KB不支持16 TB – 32 TB128 KB8 KB不支持关键对比在中间那两列同样一块 2TB 的盘格式化成 exFAT 默认是 128KB 簇格式化成 NTFS 默认是 4KB 簇两者差 32 倍。这就是为什么同一批文件从 NTFS 硬盘拷到 exFAT 的 PSSD 上占用空间会突然跳起来。所以如果你之前一直在用 NTFS 的移动硬盘从来没被这个问题困扰过换成 exFAT 的 PSSD 之后突然发现空间不够用思路不要跑偏先看簇大小。2.2 iPhone 备份、照片图库、代码仓库就是小文件重灾区不是所有数据都会触发这个问题。真正踩雷的是这几类iPhone / iPad 本地备份。备份目录Windows 在%APPDATA%\Apple\MobileSync\BackupmacOS 在~/Library/Application Support/MobileSync/Backup里的结构非常特殊每个备份由成千上万个以 40 位十六进制哈希命名的文件组成每个逻辑文件通常配一个.mddata和一个几十字节到几百字节的.mdinfo再加上大量 plist。一个用了两三年、装了几百个 App 的 iPhone备份里的文件数量轻松到 20 万到 40 万个其中相当一部分文件本身只有几百字节。这种数据形态在 128KB 簇上就是灾难。照片图库的缩略图和小尺寸资源。Apple Photos 的.photoslibrary是一个包本质是目录里面有大量几 KB 到几十 KB 的缩略图、编辑记录、元数据。整体文件数量大平均尺寸小。代码仓库和node_modules。这个不用多说几十万个几十字节到几 KB 的文件解压到 exFAT 上之后占用空间能翻好几倍。有个朋友把一个前端项目拷到 PSSD 上源目录 380MB拷过去占了 2.1GB。虚拟机镜像的小文件层。Docker 镜像层、某些虚拟机的快照链也是海量小文件。判断标准很简单文件数量除以总大小平均单文件小于 64KB 的就是重灾区。2.3 macOS 在 exFAT 上会把文件数悄悄翻倍这一条知道的人不多但影响巨大。macOS 的文件系统APFS/HFS支持扩展属性Extended Attributes和资源分支Resource Fork。而 exFAT 原生不支持这些。为了不丢数据macOS 在往 exFAT 卷写文件时会额外生成一个以._开头的伴生文件AppleDouble 格式把扩展属性、Finder 标签、自定义图标等信息塞进去。这些文件在 Finder 里默认是隐藏的你看不见但它们占空间。也就是说你在 Mac 上往 exFAT 盘里拷了 10 万个文件盘上实际躺着 20 万个文件。每个._文件通常只有几百字节到 4KB在 128KB 簇下每个又占掉一整个簇。回到刚才的例子10 万个文件加上伴生的._文件变成 20 万个每个占 128KB占用空间从 12.2GB 直接涨到 24.4GB。在终端里用ls -a或者ls -la能看到这些文件。除了._xxxmacOS 还会在卷根目录建.Spotlight-V100、.Trashes、.fseventsd、.TemporaryItems这几个隐藏目录也会占一些空间但量级远不如._文件。2.4 还有几种会让占用空间失真的情况稀疏文件被实体化。虚拟机磁盘镜像、某些数据库文件、BT 下载的预分配文件在 NTFS/APFS 上可以是稀疏的逻辑上 100GB实际只占 5GB。一旦拷到 exFAT 或 FAT32 上稀疏属性丢失100GB 就是实打实的 100GB。NTFS 压缩失效。NTFS 支持给文件或目录开启压缩属性压缩后文本类文件的占用空间可能只有原大小的三分之一。但这个属性是 NTFS 私有的复制到 exFAT 上会解压成原始大小。硬链接展开。NTFS 上一个文件可以有多个硬链接占用空间只算一份。拷到不支持硬链接的 exFAT 上每个链接都变成独立的实体文件占用成倍上涨。符号链接变成副本。同理软链接在 exFAT 上不被支持同步工具往往会直接把目标内容复制一份过去。这几条不需要都记住但当你发现明明只拷了 50GB 的东西怎么少了 200GB的时候可以挨个对号入座。3. 三步定位到底是哪些文件在虚胖知道了原理接下来就是动手。这一章给的是三个平台上的具体排查路径从最快的方法开始一步步缩小范围。3.1 Windows 端从属性面板到 WizTree第一步看属性面板。右键文件夹 → 属性面板上会同时显示大小和占用空间。如果这两个数字差得离谱比如差 50% 以上基本可以确认是簇浪费。如果资源管理器的详细信息视图里没有占用空间这一列右键列标题勾上就有了。第二步确认簇大小。这个方法跨平台通用也最直观在盘根目录建一个空的文本文件写入 1 个字节保存然后看它的占用空间。fsutil file createnew E:\probe.bin 1创建完在资源管理器里看probe.bin的占用空间。显示 4096 就是 4KB 簇显示 131072 就是 128KB 簇。这个数字就是当前文件系统的簇大小。如果是 NTFS 卷可以直接命令查fsutil fsinfo ntfsinfo E:输出里的Bytes Per Cluster就是簇大小。注意这条命令对 exFAT 无效。第三步用 PowerShell 算总账。下面这段脚本能同时算出逻辑大小和估算的分配大小判断到底浪费了多少$dir E:\Backup $B 128KB # 换成你实测的簇大小 $files Get-ChildItem $dir -Recurse -File -Force $logical ($files | Measure-Object -Property Length -Sum).Sum $alloc 0 foreach ($f in $files) { if ($f.Length -eq 0) { continue } $alloc [math]::Ceiling($f.Length / $B) * $B } 文件数量 : {0:N0} -f $files.Count 逻辑大小 : {0:N2} GB -f ($logical / 1GB) 分配大小 : {0:N2} GB -f ($alloc / 1GB) 浪费空间 : {0:N2} GB -f (($alloc - $logical) / 1GB)把$B换成实测值就行。这段脚本对大目录会跑得慢一点几十万个文件大概一两分钟但结果准。第四步想拿单个文件的精确真实占用用系统 APIAdd-Type -Namespace Win32 -Name Api -MemberDefinition [DllImport(kernel32.dll, SetLastErrortrue)] public static extern uint GetCompressedFileSizeW(string lpFileName, out uint lpFileSizeHigh); $f Get-Item E:\Backup\test.mddata $high 0 $low [Win32.Api]::GetCompressedFileSizeW($f.FullName, [ref]$high) $onDisk ([uint64]$high -shl 32) $low 逻辑大小 {0} 字节 / 实际占用 {1} 字节 -f $f.Length, $onDisk函数名里带Compressed但它对普通文件同样有效返回的就是文件实际占用的字节数。第五步可视化。想一眼看出哪个子目录最虚用 WizTree 或 TreeSize Free。WizTree 直接读 NTFS 的 MFT扫描几百万文件只要几秒。注意它对 exFAT 需要走普通扫描模式会慢一些但仍然比手动翻强得多。3.2 macOS 端Finder 根本看不出来必须上终端macOS 有个坑Finder 显示的所有大小都是逻辑大小它根本不显示分配大小。所以你在 Mac 上永远看不到那个吓人的数字只有切到 Windows 或者用终端才能看到真相。终端里对比两个命令# 分配大小实际占用 du -sh /Volumes/PSSD/Backup # 逻辑大小 find /Volumes/PSSD/Backup -type f -exec stat -f %z {} \ | awk {s$1} END {printf %.2f GB\n, s/1024/1024/1024}如果装了 GNU coreutilsbrew install coreutils可以用更简洁的写法gdu -sh --apparent-size /Volumes/PSSD/Backup gdu -sh /Volumes/PSSD/Backup--apparent-size就是逻辑大小不带这个参数就是分配大小。两个数字一比问题立马现形。看单个文件的细节stat -f 逻辑大小%z 字节, 占用块数%b, 块大小%k /Volumes/PSSD/Backup/xxx.mdinfo%b是占用的 512 字节块数量乘以 512 就是实际占用字节数。拿它和%z对比差距一目了然。查看卷的挂载信息和块大小diskutil info /Volumes/PSSD | grep -i block size\|file system顺便确认一下有没有._伴生文件ls -a /Volumes/PSSD/Backup | head -20 find /Volumes/PSSD/Backup -name ._* | wc -l如果第二个命令返回的数字接近总文件数那说明伴生文件确实把文件数翻倍了。3.3 Linux 端du 的两个口径一定要分清Linux 上最方便因为du天生就有两个模式# 逻辑大小apparent size du -sh --apparent-size /mnt/pssd/Backup # 分配大小 du -sh /mnt/pssd/Backup # 单文件对比 stat --format逻辑%s 字节, 占用%b*%B 字节 /mnt/pssd/Backup/a.bin--apparent-size是 GNU 扩展绝大多数发行版都支持。stat的%s是逻辑字节数%b是块数量%B是每块的字节数通常是 512。探测簇大小的通用土办法在 Linux 上最好用truncate -s 1 /mnt/pssd/probe.bin du -h /mnt/pssd/probe.bin rm /mnt/pssd/probe.bindu显示的数字就是簇大小可能显示成128K、4.0K这种。这个办法的原理是du默认报分配大小一个 1 字节文件必然占满一整簇。顺便看一眼挂载参数确认文件系统类型mount | grep pssd4. 解决从格式化选簇到跨平台格式选型定位完了进入实战。这一章按改动成本从高到低排列重新格式化是根治换文件系统是升级方案打包/分层是不想格盘的折中办法。4.1 实测对比同一批文件128KB 簇和 32KB 簇差多少我先说结论这次测试用的素材是一个 6.8GB 的目录里面 18.7 万个文件平均单文件约 36KB。格式化配置逻辑大小占用空间Windows 属性面板倍率exFAT / 128KB 簇6.8 GB24.2 GB3.6 倍exFAT / 32KB 簇6.8 GB11.4 GB1.7 倍NTFS / 4KB 簇6.8 GB7.3 GB1.07 倍从 128KB 簇换到 32KB 簇直接省下将近 13GB。换 NTFS 4KB 簇省得更多但代价是 macOS 上只能读不能写除非上第三方方案。这个测试说明一个事在动辄 2TB 的 PSSD 上簇大小选错等于白扔掉一两百 GB 容量。4.2 格式化时手动指定分配单元大小Windows 图形界面。右键盘符 → 格式化在分配单元大小下拉框里选。注意一个坑Windows 的格式化对话框会根据卷容量限制下拉框里的可选项2TB 的 exFAT 卷很可能最小只能选到 32KB 甚至 128KB想选 4KB 得用命令行。Windows 命令行可以强制指定format E: /fs:exFAT /a:32768 /q /v:PSSD/a:32768就是 32KB单位是字节。/q是快速格式化/v:后面是卷标。如果想用 4KB把/a:改成4096。但如果 exFAT 卷特别大、簇又特别小Windows 有时会直接拒绝原因是 FAT 表会膨胀到不合理的尺寸这是正常保护不是命令写错了。用 diskpart 更彻底diskpart list disk select disk 1 clean create partition primary format fsexfat unit32768 quick labelPSSD assign letterE exitclean会清空整块盘的分区表操作前务必确认盘号和备份。unit32768的单位是 KB写 32 就是 32KB写 4 就是 4KB。macOS 抹盘。打开磁盘工具 → 选中 PSSD → 抹掉 → 格式选 ExFAT → 方案选GUID 分区图跨平台用或主引导记录要兼容老电视、车机时用。macOS 的磁盘工具不支持自定义簇大小它只按系统默认值来。想自定义得在 Windows 或 Linux 上格然后再插回 Mac 用。这里有个提醒如果 PSSD 容量超过 2TB方案一定要选 GUID 分区图。MBR 分区表单个分区上限是 2TB选错了会导致盘只能用 2TB剩下的空间直接消失。Linux 下格式化推荐参数最全# 需要 Exfatprogs 或 exfat-utils sudo mkfs.exfat -c 32K -L PSSD /dev/sdb1-c 32K指定簇大小-L指定卷标。要 4KB 就写-c 4K。那到底该选多大给一张经验对照表主要用途PSSD 容量建议簇大小iPhone 备份、代码、海量小文档≤ 1 TB32 KB混合负载照片 视频 文档1 TB – 2 TB64 KB4K 视频素材、镜像、大文件为主≥ 2 TB128 KBNTFS 分区仅 Win/Linux 读写任意4 KB逻辑很简单小文件多就选小簇大文件多就选大簇。大簇的顺序读写性能更好、碎片更少小簇的空间利用率更高。这不是玄学是因为大簇减少了簇数量和 FAT/MFT 条目数量元数据开销小连续读写时寻址次数少。4.3 NTFS、exFAT、APFS 怎么选跨平台可读性是很多人选 exFAT 的唯一理由但这笔账要算清楚。下面这张表把三种主流方案的取舍摆明白文件系统WindowsmacOSLinux单文件上限默认簇主要代价exFAT读写读写读写16 EB大容量下 128 KB无日志掉电易损坏大簇浪费NTFS读写只读原生读写16 EB4 KBMac 上写需要第三方方案APFS不支持读写只读部分8 EB无固定簇Mac 专属FAT32读写读写读写4 GB32 KB单文件不能超 4GBext4需第三方需第三方读写16 TB4 KBLinux 专属怎么选看你的真实场景场景一只在 Windows 和 Linux 之间倒腾。直接上 NTFS4KB 簇小文件友好还有日志掉电丢数据的概率低得多Mac 只读也基本不影响。场景二Mac 和 Windows 都要频繁读写。exFAT 还是首选但格式化时把簇调小这是唯一能两头兼顾又不用装驱动的办法。同时做好心理准备exFAT 没有日志拔盘前一定要弹出。场景三主要给 Mac 用偶尔连 Windows 拷点东西。可以考虑把盘分成两个区一个 APFS 分区放 iPhone 备份和照片图库一个 exFAT 分区做中转。这样备份落在 APFS 上簇浪费几乎为零也不用担心._伴生文件。场景四要拿 PSSD 做 Windows To Go 系统盘。只能 NTFS4KB 簇别犹豫。exFAT 做不了系统盘。4.4 不想重新格式化的三种折中方案格式化要备份数据很多人嫌麻烦。下面三个办法不用格盘。方案一打包压缩小文件目录。用tar或者 7z 把海量小文件打成一个包占用空间立刻回归正常。tar -cf /mnt/pssd/backup.tar -C /source/path .但要注意一个副作用打包会破坏增量备份。iPhone 备份、Time Machine 这类机制依赖只传变化的小文件一旦打包成一个大文件每次备份都得重传整个包。所以打包适合归档不适合需要频繁增量的场景。方案二NTFS 压缩属性。如果你用的是 NTFS 分区可以给目录开压缩compact /c /s:E:\Backup\*.*文本、日志、代码类文件能压到 30%–50%。但这只在 NTFS 上有效复制到 exFAT 就解压了。方案三虚拟磁盘容器。在 exFAT 上放一个固定大小的 VHDX 文件里面格式化成 NTFSWindows 双击就能挂载挂载后小文件放在里面完全不浪费。这个方法在 Windows 上体验相当好代价是 Mac 上要挂载 VHDX 比较折腾。5. 踩坑记录与常见问题速查前面讲的都是方法和原理这一章说点只有真上手才会碰到的事。有些坑我踩过有些是帮别人救数据的时候见识的。5.1 常见问题速查表现象大概率原因处理办法大小 38GB占用 87GB簇浪费或 Mac 生成的._伴生文件检查簇大小统计._文件数量格式化后占用没变格式化时没改簇大小或只做了分区没重建文件系统用format /a:或mkfs.exfat -c强制指定拷到 exFAT 后文件变大好几倍稀疏文件实体化、NTFS 压缩失效、硬链接展开打包后再拷或改用 NTFS 分区盘上文件加起来远小于已用空间回收站、卷影副本、MFT、FAT 表Windows 清空回收站并关闭卷影副本盘突然占用异常、目录结构错乱exFAT 掉电导致的目录损坏先备份再chkdsk注意别让它乱删文件Mac 上看数字正常Windows 上看翻倍Finder 只显示逻辑大小用du或gdu看分配大小4TB 的盘只认 2TB分区表用了 MBR重新用 GUID 分区图分区5.2 我实际踩过的四个坑坑一chkdsk在 exFAT 上会吃掉文件。exFAT 没有日志掉电或热插拔后目录结构容易损坏。修复时chkdsk X: /f是标准动作但 exFAT 上的修复能力比 NTFS 弱很多它遇到无法归属的孤儿文件时倾向于把它们丢进FOUND.000隐藏目录运气不好就直接标记成坏簇回收掉空间是回来了文件也没了。提示在 exFAT 卷上跑 chkdsk 之前先把能读的文件全部拷出来。修复的顺序永远是先抢救数据再修文件系统反过来的教训我见过太多次。坑二格式化对话框里根本没有 4KB 选项。第一次给 2TB 的 PSSD 格式化想选 4KB 簇下拉框里最小只有 128KB还以为是系统版本问题。其实这是 Windows 的保护机制容量越大允许的最小簇就越高否则 FAT 表会大到不像话。绕过去的办法只有命令行format /a:。坑三Mac 上看着只拷了 30GBWindows 上显示 90GB。这个就是._伴生文件加 128KB 簇的双重打击。当时排查了半天磁盘坏道最后用find . -name ._* | wc -l数了一下20 多万个占用空间直接对上了。坑四compact压缩完再拷到 exFAT白干。在 NTFS 盘上开了压缩属性占用空间确实降了心里美滋滋然后同步到 exFAT 的 PSSD 上一看占用又回去了。原因很简单压缩是 NTFS 的私有特性换个文件系统就没了。5.3 日常维护的几个习惯用久了会发现PSSD 上占用空间对不上这个问题一半是簇浪费另一半是操作习惯造成的。几个我自己一直在用的做法插入盘之前先想清楚这块盘给谁用。只在 Win/Linux 用就 NTFS跨 Mac 就 exFAT别指望一块盘解决所有问题。每次拔盘都走弹出流程。exFAT 无日志直接拔盘的代价可能是整个目录损坏修复起来比重格式化还麻烦。定期用du/属性面板对一次账。每隔几个月看一眼大小和占用空间的比值超过 2 倍就该考虑清理或重新规划了。iPhone 备份单独放一个分区。这类数据文件数量太夸张跟其他数据混在一起会污染整块盘的统计。重要数据永远有第二份。不管文件系统怎么选单盘就是单点别把簇优化当成数据安全的替代方案。最后分享一个我反复验证过的小技巧拿不准一块新盘该怎么格的时候先拿 1000 个典型文件做一次小规模试拷看大小和占用空间的比例。比值在 1.1 倍以内说明配置合适超过 1.5 倍就该回去改簇大小了。花十分钟做这个测试比事后搬 500GB 数据省事得多。