Unix 最初设计为在内存中执行文件系统操作，并且在 期间每 30 秒仅更新一次磁盘块sync。这比多年前直接访问磁盘块执行每个文件系统操作的 MSDOS 带来了更快的用户体验。但今天使用 Windows 7 时，我仍然发现复制大量小文件所花的时间比复制一个相同大小的大文件要长得多。
例如：Visual Studio C# Asp web 项目发布目录包含 2000 个文件，总计 150 MB，压缩后（7Zip）为 90 MB。
- 将整个目录复制到同一磁盘：30秒
- 邮编：5 秒
- 复制一个压缩文件：2秒
- 解压：65 秒。（在另一台机器上：20 秒）
从计算角度来看，解压应该比压缩更快。因此，解压可能受文件系统性能的影响。
磁盘碎片可能是一个因素，也是另一台类似机器在处理许多文件系统操作时可能更快的原因。但如果磁盘碎片是一个因素，它可能表明用户必须等待每个文件系统操作完成后才能开始下一个操作，即像旧的 DOS 一样。
答案1
您描述的行为（非缓存访问）自 Windows 3.11 以来就不再使用。但是，Windows 比 Unix 更积极地刷新其缓存。这归结于它们各自的根源。Unix 机器被认为是由可靠的硬件和电源构建的。Windows PC 是廉价的机器，崩溃的频率更高。这不仅仅是操作系统的问题，UPS 在 PC 上并不常见，廉价的 IDE 磁盘在断电时不如昂贵的服务器 SCSI 磁盘可靠。古老的 FAT 格式也没有帮助 - 没有日志记录，因此存在大量损坏的可能性。NTFS 要好得多。您使用什么进行测试？
答案2
根据我自己找到的信息（见上文）以及上述贡献者提供的信息，我得出结论，现代Windows 可以进行磁盘缓冲/缓存，但此功能经常被禁用。原因包括 NTFS 没有日志功能。Windows 性能可能比利润更重要：质量与上市时间。对于商业性较差的 Unix/Linux，质量/性能更为重要。
巧合：一位同事目前正在压缩几 GB 的文件以尝试更快地复制，并在过去半小时内盯着 Windows 存档对话框，上面写着“还有 10 秒”，而 zip 文件正在缓慢增长（没有冻结）。但这也可能是磁盘故障... :-)