SSD 上的 NTFS 压缩 - 起起落落

Question

本主题讨论 HDD 上的 NTFS 压缩作为提高磁盘访问性能的一种方法，并得出结论，它通常在这方面做得很差。但我一直认为压缩是一种节省空间的方式，并在这方面了解了它的有效性。现在我有一个 SSD，它的空间很昂贵，而且性能损失，例如读/写 2 个集群而不是 1 个集群要低得多。

另一方面，由于 SSD 比 HDD 快得多，我预计更高的吞吐量将导致更高的 CPU 使用率。这会成为一个问题吗？关于这个问题还有其他想法吗？

我喜欢节省空间的效果，它不是很大，但它就在那里。但是，如果性能是一个问题，我宁愿将其关闭：

Answer 1

微软不久前在博客中写道：

NTFS 通过将数据流分成 CU 来压缩文件（这类似于稀疏文件的工作方式）。在创建或更改流内容时，数据流中的每个 CU 都会被单独压缩。如果压缩导致减少一个或多个簇，则压缩单元将以其压缩格式写入磁盘。然后一个稀疏的 VCN 范围被附加到压缩的 VCN 范围的末尾以进行对齐（如下例所示）。如果数据没有足够压缩以将大小减少一个簇，则整个 CU 以其未压缩的形式写入磁盘。

这种设计使得随机访问非常快，因为只需解压缩一个 CU 即可访问文件中的任何单个 VCN。不幸的是，大型顺序访问会相对较慢，因为执行顺序操作（例如备份）需要对许多 CU 进行解压缩。

在一篇知识库文章中写道：

虽然 NTFS 文件系统压缩可以节省磁盘空间，但压缩数据会对性能产生不利影响。NTFS 压缩具有以下性能特点。当您将压缩的 NTFS 文件复制或移动到其他文件夹时，NTFS 会解压缩该文件，将文件复制或移动到新位置，然后重新压缩该文件。即使在同一台计算机上的文件夹之间复制或移动文件时，也会发生此行为。压缩文件在通过网络复制之前也会被扩展，因此 NTFS 压缩不会节省网络带宽。

由于 NTFS 压缩是处理器密集型的，因此性能成本在服务器上更为明显，这些服务器经常受处理器限制。具有大量写入流量的高负载服务器不适合进行数据压缩。但是，对于只读、主要读取或负载较轻的服务器，您可能不会遇到显着的性能下降。

如果您运行的程序使用事务日志并不断写入数据库或日志，请将程序配置为将其文件存储在未压缩的卷上。如果程序通过压缩文件中的映射部分修改数据，则该程序生成“脏”页的速度比映射写入器写入它们的速度要快。由于此问题，Microsoft 消息队列（也称为 MSMQ）等程序无法使用 NTFS 压缩。

由于用户主文件夹和漫游配置文件使用大量读取和写入操作，因此 Microsoft 建议您将用户主文件夹和漫游配置文件放在父文件夹或卷根目录上没有 NTFS 压缩的卷上。

概括：

只压缩永远不会改变的小文件（只读取而不写入），因为读取速度很快，但写入需要解压缩和新压缩，这会占用 CPU 能力，并且存储类型并不那么重要。

Answer 2

由于克劳迪奥详细说了很多事情，我将继续他的观点，这也是我的观点，在尝试了他所说的之后，我看到了同样的效果。

对于 SSD，不得使用 NTFS 压缩。

现在我将列举一些这种肯定的动机：

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

动机二：在 SSD 上使用 NTFS 4KiB 集群会损失 50% 的 SSD 速度，检查任何基准测试，将看到 128KiB 块使 SSD 比使用 4KiB 块快两倍，并且 NTFS 压缩只能用于 4KiB 集群 NTFS 分区。

动机 3：有容器（如 PISMO File Mount）可以创建一个被视为动态压缩和/或加密的容器，此类容器在 RAM 上进行压缩，并且在重写之前不会将未压缩的数据发送到磁盘在压缩形式上，PISMO 获得比 NTFS 更好的压缩率。

还有更多的动机，但这是最重要的。

其他点是速度，任何压缩都是在 CPU 上完成的，因此如果您没有非常快的 CPU（在 NTFS 上使用单线程，而在某些容器上使用多线程）将会看到非常慢的读/写压缩时；最糟糕的是，您可以拥有一个非常快的 cpu，但是如果它用于其他用途（如渲染、转码等），则没有剩余的 cpu 用于压缩，因此您将再次获得较差的性能。

NTFS 压缩仅适用于没有太多使用 cpu 的传统慢盘，但它需要在每次写入后（在文件级别）进行良好的碎片整理，因为每个 64KiB 块（压缩或未压缩）都写入 64KiB 位置的倍数；打包此类碎片的唯一方法是在压缩（或写入压缩文件夹）后对此类文件进行碎片整理。

PD：请注意，我们谈论的是真实硬件上的 Windows，而不是虚拟机内部，重要的是谁写入物理介质，其他介质可能具有缓存层，可以减轻影响并改善很多情况。

Answer 3

我看到其他人的评论，我认为人们经常忘记 NTFS 文件/文件夹压缩在 SSD 上具有巨大优势的最有用场景：现代开发工具。我的大学授权的 Matlab在其（普通用户只读）安装文件夹中包含以下数据量：

28.5 GB 数据 30.6 GB 磁盘大小 包含 729.246 个文件和 15.000 个文件夹（!!!）

这是在我的带有 500 GB SSD 的笔记本电脑上，其中 Windows 分区是 200 GB。

我知道 Matlab 在这方面有点极端，但许多开发工具都有类似的属性：大量小型、高度可压缩的文本文件（标头、代码、XML 文件）。在安装Intel Quartus FPGA devtool之前，我正在压缩 Matlab ，并且Octave已经压缩如下：

1.55 GB 磁盘上的数据大小：839 GB 包含 34.362 个文件 1.955 个文件夹

这些东西只写一次，在项目构建过程中会被读取无数次。花费一些CPU 能力来解压缩它并节省大约一半的宝贵 SSD 空间是非常有意义的。

Answer 4

没有人谈非SSD的市长问题，就是碎片化。

每个 64KiB 块都写在它没有压缩的地方，但它可以被压缩，所以至少 <=60KiB，那么它写的小于 64KiB，位嵌套块会去它会去的地方，好像前一个不是压缩，所以有很多间隙apèars。

使用任何 windows 系统的 virtusl 机器的多 GB 文件对其进行测试（它们往往会减少 50%，但有超过 10000 个巨大的碎片）。

对于 SSD 来说，有一些东西没有被告知，它到底是怎么写的？我的意思是，如果它确实未压缩地写入它然后用压缩版本覆盖它（对于每个 64KiB 兆块），SSD 的寿命就会大大缩短；但是如果它直接以压缩形式写入，那么 SSD live 可能会更长或更短......如果你只一次写入 64KiB，则更长，如果你以 4KiB 写入 64KiB，则更短，更短，因为它会写这样的 64KiB（以压缩形式）多达 64/4=16 次。

性能损失是因为压缩/解压缩所需的 CPU 时间大于不需要写入 4KiB 块的时间......所以使用非常快的 CPU 和非常慢的磁盘压缩会减少写入和读取的时间，但如果 SSD 是非常快，CPU 很慢，它会写得慢得多。

当我谈论快速或慢速 CPU 时，我的意思是，CPU 可以被“数学”或其他进程使用，所以总是考虑免费的 CPU，而不是纸上的 CPU 规格，磁盘/SSD 也是如此，它可以被多个进程使用。

假设您有 7Zip 使用 LZMA2 从另一个磁盘写入一个大文件，它将使用大量 CPU，因此如果同时复制 NTFS 压缩文件，它没有可用的 CPU，因此它会比没有 NTFS 的速度慢压缩，但是一旦7Zip结束使用CPU，这样的CPU将能够更快地压缩NTFS，并且那时NTFS压缩可以更快地做事。

就我个人而言，我从不使用 NTFS 压缩，我更喜欢 PISMO 文件装载 PFO 容器（带压缩，并且它还允许加密，无论是动态还是对应用程序透明），它提供了更好的压缩比和更少的 CPU 影响，同时它是一个读取并即时写入，使用前无需解压，只需挂载并以读写模式使用。

由于 PISMO 在写入磁盘之前先在 RAM 上进行压缩，它可以使 SSD 的使用寿命更长，我对 NTFS 压缩的测试让我认为它会将数据发送到磁盘两次，第一次是未压缩的，然后如果它可以压缩，则以压缩形式覆盖.

为什么我的 SSD 上的 NTFS 压缩写入速度接近非压缩文件的 1/2，而不是压缩其大小的 1/2 或更低的压缩大小？在我的 AMD Threadripper 2950（32 核和 64 线程）中，内存为 128GiB（快速 CPU，非常快的 CPU），使用率不到 1%，因此有足够的 CPU 可以比 SSD 最大安全速度更快地进行压缩，这可能是因为NTFS 压缩在 64KiB 块被发送到未压缩的磁盘后开始，然后被压缩版本覆盖......哦，如果我在主机上运行 Linux 和来宾上运行 Windows 的虚拟机上执行此操作，那么 Linux 缓存会通知我这样的集群被写入两次，而且速度要快得多（Linux 正在缓存 Windows 客户机发送的非压缩 NTFS 写入，因为在它们被压缩数据覆盖之后，Linux 不会将未压缩的数据发送到磁盘，

我的建议是，不要使用 NTFS 压缩，除非在主机是 Linux 的情况下，虚拟机内的来宾会运行 Windows，如果您的 CPU 不够快，则永远不要使用 CPU。

现代SSD有一个巨大的内部ram缓存，因此可以通过SSD内部缓存系统缓解由NTFS压缩引起的write+overwtite。

我的测试是在“漂亮”的 SSD 上完成的，SSD 内部没有用于缓存的内部 RAM，当我在带有 ram 缓存的那些上重复它们时，写入速度很快，但不像人们想象的那样。

做你自己的测试，并使用巨大的文件大小（大于安装的总 tam 以避免缓存隐藏结果）。

顺便说一下，有些人不知道 NTFS vompression ......任何 4KiB 或更低的文件永远不会得到 NTFS 压缩，因为没有办法将其大小减少至少 4KiB。

NTFS压缩占用64KiB的块，压缩它们，如果它可以减少一个簇（4KiB）那么它被压缩写入，64KiB是4KiB的16个块（连续）。

如果压缩结束时 8KiB 的文件超过 4KiB，则不会保存任何集群，因此将其写入未压缩，......等等......压力必须至少获得 4KiB。

啊，对于 NTFS 压缩，NTFS 的簇大小必须为 4KiB。

尝试做一个测试：在 SSD 上的 NTFS 上使用 128KiB 集群你会看到写入和读取速度的巨大性能提升。

具有 4KiB 集群的 SSD 上的文件系统正在失去很多速度，在大多数情况下损失超过 50%……查看任何使用不同块大小进行测试的基准，从 512 字节到 2MiB，大多数 SSD 写入双倍在 64KiB（或 128KiB）集群大小上比在 4KiB 上速度更快。

想要对您的 SSD 进行真正的启发？不要在文件系统上使用 4KiB 集群，使用 128KiB。

如果超过 99% 的文件小于 128KiB，则仅使用 4KiB 集群。

等等等等等等...测试，测试和测试你自己的案例。

注意：在使用 128KiB 集群安装 Windows 或从另一个 Windows 时，在控制台模式下使用 diskpart 创建系统 NTFS 分区，但不要在安装程序图形部分时让 Windows 格式化（它总是将其格式化为 4KiB 集群 NTFS）。

我所有的 Windows 现在都安装在 >400GiB SSD (SLC) 上的 128KiB 集群 NTFS 分区上。

希望事情会清楚，M$ 并没有说明我如何压缩 NTFS，我的测试告诉我它写了两次（64KiB 未压缩，然后 <=60KiB 压缩），而不是一次（如果在 SSD 上，请注意这一点）。

注意：Windows 尝试对一些内部目录进行 NTFS 压缩，无论您是否说没有 NTFS 压缩，如果 NFTS 集群大小与 4KiB 不同，这是真正避免这种情况的唯一方法，因为 NTFS 压缩仅适用于 4KiB 集群大小的 NTFS 分区