这个话题讨论了 HDD 上的 NTFS 压缩作为提高磁盘访问性能的一种方法，并得出结论，这种方法通常在这方面表现不佳。但我一直认为压缩是一种节省空间的方法，并且了解了它的有效性。现在我有一块 SSD，空间很贵，但性能损失（例如，读取/写入 2 个簇而不是 1 个簇）要低得多。
另一方面，由于 SSD 比 HDD 快得多，我预计更高的吞吐量将导致更高的 CPU 使用率。这会成为一个问题吗？对此事还有其他想法吗？
我喜欢节省空间的效果，虽然不是很大，但确实存在。但如果性能是一个问题，我宁愿关闭它：
答案1
NTFS 通过将数据流划分为 CU 来压缩文件（这与稀疏文件的工作方式类似）。当创建或更改流内容时，数据流中的每个 CU 都会被单独压缩。如果压缩导致一个或多个簇减少，则压缩单元将以其压缩格式写入磁盘。然后，将稀疏 VCN 范围附加到压缩 VCN 范围的末尾以进行对齐（如下例所示）。如果数据压缩程度不足以将大小减少一个簇，则整个 CU 将以其未压缩形式写入磁盘。
这种设计使得随机访问非常快，因为只需解压一个 CU 即可访问文件中的任何单个 VCN。不幸的是，大规模顺序访问会相对较慢，因为需要解压许多 CU 才能执行顺序操作（例如备份）。
并且在知识库文章写道：
虽然 NTFS 文件系统压缩可以节省磁盘空间，但压缩数据会对性能产生不利影响。NTFS 压缩具有以下性能特征。当您将压缩的 NTFS 文件复制或移动到其他文件夹时，NTFS 会解压缩该文件，将该文件复制或移动到新位置，然后重新压缩该文件。即使在同一台计算机上的文件夹之间复制或移动该文件，也会发生此行为。压缩文件在通过网络复制之前也会被展开，因此 NTFS 压缩不会节省网络带宽。
由于 NTFS 压缩处理器密集型，性能成本在经常受处理器限制的服务器上更为明显。负载重且写入流量大的服务器不适合进行数据压缩。但是，对于只读、主要读取或轻负载的服务器，您可能不会遇到明显的性能下降。
如果您运行使用事务日志记录并不断写入数据库或日志的程序，请配置该程序以将其文件存储在未压缩的卷上。如果程序通过压缩文件中的映射部分修改数据，则该程序产生的“脏”页的速度会比映射写入器写入的速度快。由于此问题，Microsoft Message Queuing（也称为 MSMQ）等程序无法与 NTFS 压缩配合使用。
由于用户主文件夹和漫游配置文件使用大量的读写操作，因此 Microsoft 建议您将用户主文件夹和漫游配置文件放在父文件夹或卷根目录上没有 NTFS 压缩的卷上。
概括：
只压缩那些永远不会改变的小文件（只读取而不写入），因为读取速度很快，但写入需要解压缩和新的压缩，这需要 CPU 能力，而存储类型并不那么重要。
答案2
由于克劳迪奥详细地说了很多事情，我将重申他的观点，这也是我的观点，在尝试了他所说的之后，我看到了同样的效果。
对于 SSD，不能使用 NTFS 压缩。
现在我将列举一些作出这种肯定的动机：
动机 1：它将更快地杀死 SSD，因为它进行了两次写入；NTFS 压缩总是在开始压缩之前将未压缩的数据写入 RAM，然后仅当增益至少为 4KiB 时才重写压缩数据。
动机 2：在 SSD 上使用 NTFS 4KiB 集群会使 SSD 速度损失 50%，检查任何基准测试都会看到 128KiB 块使 SSD 比使用 4KiB 块快两倍，并且 NTFS 压缩只能在 4KiB 集群 NTFS 分区上使用。
动机 3：有些容器（例如 PISMO File Mount）可以创建被视为动态压缩和/或加密的容器，这种容器在 RAM 上进行压缩，并且在以压缩形式重写之前不会将未压缩的数据发送到磁盘，而且 PISMO 的压缩率比 NTFS 更好。
还有更多的动机，但这些是最重要的。
另一点是速度，任何压缩都是在 CPU 上完成的，因此如果你没有非常快的 CPU（NTFS 上使用单线程，而某些容器上使用多线程），则压缩时读/写速度会非常慢；最糟糕的是，你可能有一个非常快的 CPU，但如果它用于其他事情（如渲染、转码等），就没有剩余的 CPU 用于压缩，因此你再次会得到糟糕的性能。
NTFS 压缩仅适用于 CPU 不怎么使用的传统慢速磁盘，但它要求在每次写入（在文件级别）后进行良好的碎片整理，因为每个 64KiB 块（无论是否压缩）都写入 64KiB 位置的倍数；打包此类碎片的唯一方法是在压缩后（或在压缩文件夹中写入）对此类文件进行碎片整理。
PD：请注意，我们谈论的是真实硬件上的 Windows，而不是虚拟机内部，重要的是谁写入物理介质，其他人可能有缓存层，可以减轻影响并大大改善情况。
答案3
我看到了其他人的评论，我认为人们经常忘记 NTFS 文件/文件夹压缩在 SSD 上具有巨大优势的最有用的场景：现代开发工具。我的大学授权的 Matlab在其（普通用户只读）安装文件夹中包含以下数量的数据：
28.5 GB 数据 30.6 GB 磁盘大小 包含 729.246 个文件和 15.000 个文件夹（！！！）
这是在我的笔记本电脑上，配备 500 GB SSD，其中 Windows 分区为 200 GB。
我知道 Matlab 在这方面有点极端，但许多 devtools 都有类似的特性：大量小型、高度可压缩的文本文件（标题、代码、XML 文件）。我现在正在安装之前压缩 Matlab英特尔 Quartus FPGAdevtool，以及八度已经压缩如下：
1.55 GB 磁盘上的数据大小：839 GB 包含 34.362 个文件 1.955 个文件夹
这些内容只需编写一次，在项目构建期间就会被读取无数次。花费大量时间进行开发是完全合理的。一些CPU 能力来解压缩它并节省大约一半的宝贵 SSD 空间。
答案4
您需要进行两次基准测试才能知道。压缩。未压缩。忘记 SSD 上的磨损。您需要快速的 SSD 和 CPU，这样就不会出现瓶颈。
如今，512GB 的 SSD 售价为 50 美元。到目前为止，对我来说最快的磁盘访问方式是尽可能使用 Linux 和 LIFO 磁盘队列机制。而不是 CFQ。
我的笔记本电脑上安装了 12GB 内存，Windows 10 会产生无限的磁盘活动。Linux mint 加载后几乎没有磁盘访问。除非您启动它。Windows 有办法让自己保持忙碌，而没有可见的任务。