☰

使用压缩时，NTFS 是否会将文件写入两次？

tag-icon • tag-icon windows ssd ntfs compression
使用压缩时，NTFS 是否会将文件写入两次？

我已阅读此答案https://superuser.com/a/1358858/1506333NTFS 确实进行双重写入，先写入未压缩的数据，然后再写入压缩的数据，这是真的吗？

动机 1：它将更快地杀死 SSD，因为它进行了两次写入；NTFS 压缩总是在开始压缩之前将未压缩的数据写入 RAM，然后仅当增益至少为 4KiB 时才重写压缩数据。

还有这些

答案1

我也对此感兴趣，但除了提出这一主张的人之外找不到任何其他来源。所以是时候进行一些原创研究了。

总结

至少对于 Windows 10 来说，

  • 索赔 ”NTFS 压缩将文件数据写入两次“ 是破获
  • 索赔 ”NTFS 压缩总是会导致文件高度碎片化“ 是破获

我所做事情的细节：

我在 KVM 虚拟机中运行了完全更新的 Windows 10，并连接了一个新的、空的、模拟的 15GB SSD，禁用了缓存并配备了 KVM，以测量 Windows 向硬件发出的实际写入。

（除非另有说明，否则为 SI 单位）

  • 结果 0a：原始稀疏磁盘映像最初使用 2MB
  • 结果 0b：对驱动器进行分区/格式化写入 49MB
  • 结果 0c：磁盘映像增长到 53M

实验一：将由二进制零组成的 1GiB 文件从 samba 共享复制到新创建的磁盘（通过拖入资源管理器）。

  • 结果 1a：这物理上向磁盘写入了 3650kB
  • 结果 1b：磁盘映像没有增长
  • 结果1c：文件属性显示该文件占用0字节
  • 结果 1d：contig 显示文件已完全碎片整理

实验2：删除该文件，使用 Windows 资源管理器复制一个由高度可压缩数据（重复的 0x790a）组成的 1GB 文件。

  • 结果 2a：这在物理上向磁盘写入了 72MB
  • 结果 2b：磁盘映像确实增长到 116MB
  • 结果 2c：文件属性显示该文件占用 63MB
  • 结果 2d：contig 显示文件使用了 2 个片段

实验3：禁用压缩，将相同的文件再次复制到磁盘。

  • 结果 3a：这实际上向磁盘写入了 1003MB
  • 结果 3b：磁盘映像确实增长到 1.5GB
  • 结果3c：文件属性显示该文件占用1000MB
  • 结果 3d：contig 显示文件使用 1 个片段

实验4：使用资源管理器属性压缩此文件。

  • 结果 4a：这实际上向磁盘写入了 75MB
  • 结果4b：文件属性显示该文件占用63MB
  • 结果 4c：contig 显示文件使用了 4 个片段
  • 结果 4d：contig 显示驱动器有 4 个可用空间碎片

实验5：创建了一个 5GB 的磁盘和分区，将一个 10GB 的高度可压缩文件复制到其中，使用“类型”（explorer/copy 立即拒绝，因为目标驱动器不够大）。

  • 结果 5a：写入 4600MB 后中止
  • 结果 5b：这在物理上向磁盘写入了 397MB
  • 结果 5c：磁盘映像确实增长到 548MB
  • 结果5d：文件属性显示该文件占用280MB
  • 结果 5e：contig 显示文件使用了 57 个片段
  • 结果 5f：contig 显示驱动器有 24 个可用空间碎片

总体观察1：在写入文件时，Windows 开始写入速度相对较快（5MB/s），但在复制“完成”后，它继续写入超过 40 秒，速度不断降低（最后几秒从 500kB/s 降至 54kB/s）。这有点奇怪，可能会导致人们相信在写入文件后后台发生了一些事情。

总体观察2：即使是“类型”这样简单的命令也非常慢。

总体观察3：Windows 显然在压缩时会识别出带有零的块，或者自动将连续的零检测为稀疏文件（源文件不稀疏）。这令人惊讶。

花饰：在（最近）过去，我发现文件使用 NTFS 压缩获得了数百万个碎片（主要是 Unity“WindowsNoEditor”游戏包文件），因此 NTFS 有时确实会出现这种情况，但这似乎仅限于某些文件和/或某些条件，并且通常是罕见的情况（我在我的 3TB 压缩磁盘上的 1949979 个文件中发现了 15 个以显示这种模式）。

相关内容