使用压缩时NTFS会写入两次文件吗？

Question

我在这个答案中读到https://superuser.com/a/1358858/1506333 NTFS会进行双重写入，首先未压缩数据，然后压缩，是真的吗？

\n

\n

Motive N\xc2\xba1：它会更快地杀死 SSD，因为它会进行两次写入；NTFS 压缩始终在开始压缩之前将未压缩的数据写入 RAM，然后仅在获得至少 4KiB 的增益时才重新写入压缩数据。

\n

\n

还有这些

\n

\n
• NTFS 压缩真的是即时压缩吗？
\n
• 当我在“NTFS 压缩”目录中创建文件时会发生什么？
\n
• 使用透明压缩文件
\n
• 如果我在 SSD 上选中“压缩此驱动器以节省磁盘空间”框会怎样？
\n

\n

Answer 1

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

长话短说

至少对于 Windows 10 来说，

• “ NTFS 压缩将文件数据写入两次”的说法已被驳斥
• “ NTFS 压缩总是会导致文件高度碎片化”的说法已被推翻

我所做的详细信息：

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

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

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

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

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

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

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

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

• 结果 3a：这将 1003MB 物理写入磁盘
• 结果 3b：磁盘映像确实增长到 1.5GB
• 结果3c：文件属性显示该文件占用1000MB
• 结果 3d：重叠群显示文件使用 1 个片段

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

• 结果 4a：这将 75MB 物理写入磁盘
• 结果4b：文件属性显示该文件占用63MB
• 结果 4c：重叠群显示文件使用 4 个片段
• 结果 4d：重叠群显示驱动器具有 4 个可用空间碎片

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

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

总体观察1：写入文件时，Windows开始写入速度相对较快（5MB/s），但在复制“完成”后，它继续写入40多秒，速度不断下降（500kB/s降至54kB/s）最后几秒钟）。这有点奇怪，并且可能会让人相信写入文件后后台会发生某些事情的理论。

总体观察2：即使是简单的命令（例如“type”）也慢得惊人。

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

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