SSD上的NTFS压缩-起伏不定

本主题讨论了对HDD进行NTFS压缩，将其作为提高磁盘访问性能的一种方法，并得出结论说，这样做通常较差。但是我一直将压缩视为节省空间的一种方式，并由此了解了压缩的有效性。现在我有了一个固态硬盘，其中的空间非常昂贵，并且性能下降，例如读取/写入2个群集（而不是1个群集）要低得多。

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

我喜欢节省空间的效果，它虽然不大，但是确实存在。但是，如果性能是一个问题，我宁愿将其关闭：

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

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

由于仅需要解压缩一个CU才能访问文件中的任何单个VCN，因此该设计使随机访问变得非常快。不幸的是，大型顺序访问将相对较慢，因为执行顺序操作（例如备份）需要对许多CU进行解压缩。

并在KB文章中写道：

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

因为NTFS压缩是处理器密集型的，所以性能成本在服务器（通常受处理器限制）上更为明显。重载的服务器具有大量写流量，因此不适合用于数据压缩。但是，对于只读，只读或负载较轻的服务器，您可能不会遇到明显的性能下降。

如果运行的程序使用事务日志记录并不断写入数据库或日志，请配置该程序以将其文件存储在未压缩的卷上。如果程序通过压缩文件中的映射节修改数据，则该程序产生“脏”页面的速度比映射编写器写入它们的速度更快。由于此问题，诸如Microsoft消息队列（也称为MSMQ）之类的程序不适用于NTFS压缩。

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

摘要：

仅压缩由于读取速度快而永不更改的小文件（仅读取和不写入），但写入需要解压缩，而新压缩需要占用CPU功率，并且存储类型不是很重要。

正如克劳迪奥详细说了很多话一样，我将继续他的观点，这也是我的观点，我尝试了他的观点后也看到了同样的效果。

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

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

动机Nº1：因为它会进行两次写入，所以它将更快地杀死SSD的混乱。在开始对RAM进行压缩之前，NTFS压缩始终写入未压缩的数据，然后仅在获得至少4KiB的增益时才重新写入压缩的数据。

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

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

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

OTRER点是SPEED，任何压缩都在CPU上完成，因此，如果您没有非常快的CPU（NTFS上使用单线程，而某些容器上使用多线程）则将看到非常慢的读/写压缩时 最糟糕的是，您可以拥有非常快的cpu，但是如果将其用于其他用途（例如渲染，转码等），则将没有用于压缩的cpu，因此，您的性能将再次下降。

NTFS压缩仅在没有太多使用cpu的情况下才适用于传统的慢速磁盘，但是由于每个64KiB块（压缩或未压缩）都以64KiB的倍数写入，因此每次写入（文件级）后都需要进行良好的碎片整理。压缩此类碎片的唯一方法是在压缩（或在压缩文件夹中写入）后再对此类文件进行碎片整理。

PD：当心，我们谈论的是Windows，而不是虚拟机上的真实硬件，重要的是谁写物理介质，其他的可能具有缓存层，这些缓存层可以减轻影响并改善很多东西。

没有人谈论非SSD上的市长问题，这是分散的。

每个64KiB块都在没有压缩的情况下写入，但可以压缩，因此至少为<= 60KiB，然后写入少于64KiB，位嵌套块将到达与上一个未压缩的位置相同的位置压缩，所以差距很大。

使用任何Windows系统的virtusl机器的千兆字节文件进行测试（它们通常会减少50％，但会有大于10000个巨大片段）。

对于固态硬盘，有些事情没有告诉，它到底是怎么写的？我的意思是，如果确实将其未压缩地写入，然后用压缩版本覆盖（对于每个64KiB mega块），则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的ram（快速CPU，非常快的CPU），使用率不到1％，因此有足够的CPU进行压缩，其速度超过SSD最大安全速度。将64KiB块发送到未压缩的磁盘后再开始使用NTFS压缩，然后用压缩的版本覆盖...哦，如果我是在运行Linux的虚拟机上进行此操作的，而该虚拟机在主机上运行Linux，在来宾上运行Windows，则Linux缓存会通知我该集群被写入两次，而且速度快得多（Linux正在缓存Windows guest发送的非压缩NTFS写入，并且由于它们被压缩数据覆盖后，Linux不会将未压缩的数据发送到磁盘，

我的建议是，不要使用NTFS压缩，除非在虚拟机内部，如果主机是Linux，则guest虚拟机运行Windows，并且如果CPU使用速度不够快，则决不要使用CPU过多。

现代SSD具有巨大的内部ram缓存，因此SSD内部缓存系统可以减轻NTFS压缩引起的写入和覆盖。

我的测试是在“漂亮的” SSD上完成的，没有内部RAM用于SSD内的缓存，当我在具有ram缓存的内存上重复这些测试时，写入速度是最快的，但是却没有人想到。

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

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

NTFS压缩需要64KiB的容量，然后对其进行压缩，如果可以减少一个群集（4KiB），则将其写入压缩状态，64KiB是16个4KiB块（连续）。

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

嗯，对于NTFS压缩，NTFS必须具有4KiB的群集大小。

尝试进行测试：在SSD的NTFS上使用128KiB群集，您将看到写入读取速度方面的巨大性能提升。

具有4KiB群集的SSD上的文件系统的速度降低了很多，大多数情况下损失了50％以上...看到那里有任何基准可以测试不同的块大小，从512Bytes到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分区

我看到其他人的评论，并且我认为人们经常忘记最有用的方案，即NTFS文件/文件夹压缩在SSD上具有很大的优势：现代开发工具。我的大学许可的Matlab在其（对于普通用户只读）安装文件夹中具有以下数据量：

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

这是在具有500 GB SSD的笔记本电脑上，Windows分区为200 GB。

我知道Matlab在这方面有点极端，但是许多devtool具有相似的属性：大量的小型，高度可压缩的文本文件（标头，代码，XML文件）。在安装英特尔Quartus FPGA devtool 之前，我现在正在压缩Matlab ，并且Octave已按以下方式进行压缩：

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

这些东西只写了一次，在项目构建过程中读了无数次。花费一些 CPU能力对其进行解压缩并节省大约一半的宝贵SSD空间是非常合理的。

您需要进行两次基准测试才能知道。压缩的。未压缩。不用担心SSD的磨损。您需要快速的ssd和CPU，因此不会出现瓶颈。

如今，512GB的SSD售价为50美元。到目前为止，对我来说最快的磁盘访问是在可能的情况下使用Linux和LIFO磁盘队列机制。而不是CFQ。

Windows 10使用笔记本电脑上安装的12GB内存创建无限磁盘活动。Linux Mint加载之后，几乎发生了零磁盘访问。除非您启动它。Windows只是有一种使自己忙碌而没有可见任务的方法。