GridFS删除文件后磁盘空间不释放是WiredTiger引擎的设计行为，仅标记空间为“可复用”而不归还OS；compact命令效果差因需停写、不缩文件大小且对小chunk碎片优化低；repairDatabase已弃用且对GridFS无效；真正释放空间须停服导出重建或在线执行compactServer+fstrim。
GridFS 删除文件后磁盘空间不释放，不是误操作或配置错误，而是 WiredTiger 引擎的默认行为——它把删除空间标记为“可复用”，但不会主动归还给操作系统。
WiredTiger 不返还磁盘空间是设计使然
WiredTiger 优先保障写入吞吐和崩溃恢复能力，内部通过 allocated list、available list 和 discard list 管理空间。当你调用 GridFSBucket.delete() 或手动删 fs.files + fs.chunks 文档时：
- 只是把对应数据块从
allocated list移到discard list - 这些块在下一个 checkpoint 后才进入
available list，供新写入复用 - mongod 进程本身不会触发
fsync+fallocate(FALLOC_FL_PUNCH_HOLE)类系统调用去真正“打洞”释放磁盘
compact 命令对 fs.chunks 效果差的三个原因
执行 db.runCommand({compact: "fs.chunks"}) 看似合理，但实际收效甚微：
- 必须停写：整个集合被独占锁定，业务读写全部阻塞
- 不改变
.wt文件大小：只重排页内碎片，不 shrink 文件长度 - chunk 文档太小（默认 256KB），大量删除后残留的是细碎空洞，WiredTiger 的 compact 机制对这种场景优化效率极低
repairDatabase 对 GridFS 完全无效且已弃用
别再试 db.repairDatabase() 或 db.runCommand({repairDatabase: 1})：
- MongoDB 4.2+ 已正式弃用该命令
- 它从不支持 WiredTiger 引擎下的空间回收，对 GridFS 所在数据库直接返回错误或静默忽略
- 即使旧版本能跑，也只作用于 MMAPv1 引擎，而 GridFS 几乎全跑在 WiredTiger 上
真正释放磁盘空间只有两条路
想让 df -h 显示的空间变小，必须打破 WiredTiger 的文件复用链：
- 停服方案：用
mongodump --gzip --db your_db --collection fs.files --collection fs.chunks导出，清空storage.dbPath下所有*.wt文件，再mongorestore—— 此时 WiredTiger 以全新文件写入，无任何碎片 - 在线方案（仅限 SSD + XFS/ext4 +
fstrim）：先db.adminCommand({compactServer: true})，再在宿主机执行fstrim /var/lib/mongodb，依赖底层文件系统 TRIM 支持
最容易被忽略的一点：GridFS 删除逻辑正确 ≠ 空间释放。哪怕你用 GridFSBucket.delete() 完全按规范走，只要没走上面任一物理重建路径，df 就不会变。
