往盘里写完一批大文件，脚本报告"写入完成"，可你随手一看磁盘可用空间——还是写之前那个数，几乎没变。心里一紧：文件到底写进去了没有？是写入失败了没报错，还是统计读错了？再去看文件，文件明明在，大小也对。这中间的落差，就是缓存造成的。
现象
具体表现：
- 刚写完一批大文件（比如转存一批镜像、导出一批数据）；
- 立刻查询磁盘可用空间，数字和写入前差不多，看起来像没写进去；
- 但文件确实存在、大小也对；
- 过一会儿再查，空间数字才更新，显示为正确的可用值。
在 Linux 的一些文件系统（尤其是某些网络文件系统、以及有延迟统计行为的本地文件系统）上，这个滞后比较常见。
根因
根本原因是文件系统的空间统计存在延迟，而这个延迟通常来自缓存。
现代文件系统普遍使用内存缓存来提升写入性能。程序写完数据后，数据并不一定立刻全部落盘——它可能先待在内存（缓存）里，由内核在合适的时候批量刷写到设备。这样做能极大提高吞吐、减少设备压力，是个正常的、刻意的设计。
在这段"数据还在缓存、尚未完全落盘"的窗口期内，文件系统对空间使用量的统计可能有两个口径：
- 逻辑口径：按已分配的文件算，可能已经计入；
- 物理口径：按真正落盘、从设备角度看已占用的块算，可能还没更新。
当查询读到的是滞后的那个口径时，你看的数字就偏旧了。另外，有些文件系统的空闲空间统计本身是异步刷新的——它不是每次查询都实时重算，而是定期或有触发条件时才更新。这两个因素叠加，就让"刚写完"的这个时刻最容易读到旧值。
关键认识："空间统计没变"不等于"数据没写进去"。统计是滞后的视图，不是实时真相。
解决
在判断之前，先同步一次。 同步会把缓存里的数据刷写到设备，并让文件系统状态与实际一致：
# 把所有缓存中的数据刷写到磁盘
sync
# 然后再查可用空间
df -h
sync 的作用是让内核把脏数据（已经写了但还在缓存里的）全部落盘。执行之后再查 df -h，空间统计通常就正常了。
如果要脚本里判断"写入是否完成、空间是否释放"，也别在写完的那一刻立刻下结论，可以：
- 写入完成后先
sync，再读df； - 或者读文件本身的属性（大小、校验和）来确认数据写对了，空间数字作为次要参考；
- 对需要精确判断的场景，用
sync <单个文件>（只同步某个文件）减少全局影响。
# 只同步指定文件/路径
sync /path/to/largefile.img
df -h /path/to/mountpoint
在 Windows 上，等价的概念是缓存刷写；正常关闭句柄（程序正常退出或显式 flush）就会让统计更新，一般不需要手工干预。如果遇到类似的"空间没变"，用文件自身的大小和系统"卷属性"里的值交叉核对即可。
延伸与预防
这条坑的通用价值，是那个反复出现的原则："看到的值"和"实际的状态"之间可能有时间差。
缓存、异步刷新、延迟统计、最终一致性——这些机制广泛存在于系统的各个层面：文件系统的空间统计、数据库的主从复制延迟、缓存与源数据的不一致、监控指标采集与上报的时间差、云控制台展示的资源状态……它们都是"为了性能牺牲实时性"的产物，本身没有错，但会让人在写入后的瞬间读到与预期不符的值。
因此，在"刚做完 A，立刻检查 B"的场景里，要养成两个习惯：
- 先同步，再判断：用
sync、flush、强制刷盘之类的动作，把异步的滞后收敛掉，再读数； - 用直接证据而不是间接统计：判断"数据写进去了没有"，看文件本身（大小、内容、校验）比看"空间变了没有"更可靠；判断"配置生效了没有"，看进程实际加载的值比看配置文件的修改时间更可靠。
把这个"先收敛时间差、再用直接证据"的思路记住，能省掉大量"是不是没生效"的自我怀疑。