HDD 或 SSD 上还有多少可用空间？

Question

在非正式（即新闻）技术出版社以及在线技术博客和讨论论坛中，人们通常会遇到一些轶事建议，即在硬盘驱动器或固态驱动器上留出一些可用空间。给出了各种原因，有时根本没有原因。因此，这些说法虽然在实践中可能是合理的，但它们具有神话色彩。例如：

• 一旦您的磁盘已满 80%，您应该认为它们已满，您应该立即删除内容或升级。如果它们达到90%满，你应该考虑你自己的裤子真的着火了，并立即做出适当的反应来补救。（来源。）

• 为了保持垃圾收集以最高效率运行，传统建议的目标是保持 20% 到 30% 的驱动器空闲。（来源。）

• 有人告诉我，我应该在 HD 上留出大约 20% 的空闲时间以获得更好的性能，当 HD 接近满时，它确实会变慢。（来源。）

• 您应该为交换文件和临时文件留出空间。我目前保留 33% 的可用空间，并发誓不会获得低于 10GB 的可用硬盘空间。（来源。）

• 我会说通常是 15%，但是现在有多大的硬盘驱动器，只要您有足够的临时文件和交换文件，从技术上讲，您是安全的。（来源。）

• 我建议在 Windows 上使用 10% 以上，因为如果运行它时驱动器上没有那么多空闲，碎片整理将不会运行。（来源。）

• 您通常希望留出大约 10% 的空闲时间以避免碎片化（Source。）

• 如果您的驱动器的容量始终超过 75% 或 80%，则值得考虑升级到更大的 SSD。（来源。）

是否有任何关于操作系统、文件系统和存储技术（例如磁碟与固态）的特定组合所需的可用空间百分比或绝对量的研究（最好在同行评审期刊上发表）？（理想情况下，此类研究还可以解释不超过特定已用空间量的原因，例如为了防止系统耗尽交换空间，或避免性能损失。）

如果您知道任何此类研究，我将不胜感激，如果您能回答它的链接以及研究结果的简短摘要。谢谢！

Answer 1

虽然我不能谈论由“同行评审期刊”发表的“研究”——我不想在日常工作中依赖这些——但我可以谈论数百种生产的现实多年来在各种操作系统下的服务器：

满盘会降低性能的原因有以下三个：

• 可用空间不足：想想临时文件、更新等。
• 文件系统降级：如果没有足够的空间，大多数文件系统都无法优化文件布局
• 硬件级别降级：没有足够可用空间的 SSD 和 SMR 磁盘将显示吞吐量下降，甚至更糟的是延迟增加（有时会增加许多数量级）

第一点是微不足道的，特别是因为没有理智的生产系统会在动态扩展和收缩文件时使用交换空间。

第二点在文件系统和工作负载之间存在很大差异。对于混合工作负载的 Windows 系统，70% 的阈值非常有用。对于文件很少但文件很大的 Linux ext4 文件系统（例如视频广播系统），这可能会达到 90+%。

第三点取决于硬件和固件，但特别是带有 Sandforce 控制器的 SSD 可能会在高写入工作负载的空闲块擦除中回落，导致写入延迟增加数千个百分点。我们通常在分区级别留出 25% 的空闲空间，然后观察到低于 80% 的填充率。

建议

我意识到我提到了如何确保执行最大填充率。一些随意的想法，没有一个是“同行评审”（付费的、伪造的或真实的），而是所有来自生产系统的想法。

• 使用文件系统边界：/var不属于根文件系统。
• 监测，监测，监测。如果适合您，请使用现成的解决方案，否则解析 的输出df -h并让警报响起以防万一。这可以使您免于在根 fs 上使用 30 个内核，并且安装和运行自动升级而不使用 autoremove 选项。
• 首先权衡 fs 溢出的潜在破坏与使其更大的成本：如果您不在嵌入式设备上，您可能只需将 4G 翻倍即可获得 root 权限。

Answer 2

是否有任何研究……研究操作系统、文件系统和存储技术的特定组合所需的可用空间的百分比或绝对数量……？

在 20 年的系统管理工作中，我从未遇到过详细说明各种配置的可用空间要求的研究。我怀疑这是因为计算机的配置多种多样，由于可能的系统配置数量众多，因此很难做到。

要确定系统需要多少可用空间，必须考虑两个变量：

1. 防止不需要的行为所需的最小空间，它本身可能有一个流动的定义。

   请注意，仅通过此定义来定义所需的可用空间是没有帮助的，因为这相当于说以 80 英里/小时的速度向砖墙行驶直到与砖墙相撞是安全的。

2. 存储消耗的速度，这决定了要保留的额外可变空间量，以免系统在管理员有时间做出反应之前降级。

操作系统、文件系统、底层存储架构以及应用程序行为、虚拟内存配置等的特定组合对希望提供明确的可用空间要求的人来说是一个相当大的挑战。

这就是为什么有这么多“建议”的原因。您会注意到他们中的许多人围绕特定配置提出了建议。例如，“如果您的 SSD 在接近容量时会出现性能问题，请保持 20% 以上的可用空间。”

因为没有简单的回答这个问题，正确的方法，以确定您的系统的最小可用空间的要求是要考虑各种通用的建议，在光系统的具体配置，然后设置一个门槛，监视它，并愿意进行调整有必要的。

或者您可以保留至少 20% 的可用空间。当然，除非你有一个 42 TB RAID 6 卷，由 SSD 和传统硬盘和预先分配的交换文件的组合支持......（这对严肃的人来说是个笑话。）

Answer 3

是否有任何研究，最好发表在同行评审的期刊上 [...]？

为此，人们必须回溯 20 多年，无论是系统管理还是其他方面。至少在 30 多年前，这在个人计算机和工作站操作系统领域是一个热门话题；在 BSD 人员开发 Berkeley Fast File?System 和 Microsoft 和 IBM 开发高性能文件?系统的时候。

其创建者的文献讨论了这些文件系统的组织方式，以便块分配策略通过尝试使连续的文件块连续来产生更好的性能。您可以在有关该主题的当代文章中找到有关此问题的讨论，以及用于分配块的空闲空间的数量和位置会影响块放置并进而影响性能这一事实。

应该是相当明显的，例如从 Berkeley FFS 的块分配算法的描述中可以看出，如果当前柱面组和次柱面组中没有空闲空间，则算法因此达到第四级回退（“apply an exhaustive搜索所有柱面组”），分配磁盘块的性能会受到影响，文件碎片也会受到影响（因此也会影响读取性能）。

过去 30 年来公认的智慧建立在这些和类似的分析（这些远不是旨在改进当时文件系统设计的布局策略的唯一文件系统设计）的基础上。

例如： 原始论文中基于创建者的实验，FFS 卷保持小于 90% 满，以免性能受到影响的格言，即使在本世纪出版的 Unix 文件系统书籍中也可以找到不加批判地重复^{（例如, Pate2003 第 216 页）}。很少有人质疑这一点，尽管 Amir H. Majidimehr 实际上在一个世纪之前就做过，他说 xe 在实践中没有观察到明显的影响；尤其是因为习惯的 Unix 机制将最后 10% 保留给超级用户使用，这意味着 90% 满的磁盘无论如何 对于非超级用户来说实际上是 100% 满^{(Majidimehr1996 p. 68)}. Bill Calkins 也是如此，他建议在实践中可以用 21 世纪的磁盘大小填充 99%，然后再观察低可用空间的性能影响，因为即使是 1% 的现代大小的磁盘也足以拥有大量未碎片化的可用空间仍然可以玩^{（Calkins2002 p. 450）}。

后者是一个例子，说明接受的智慧是如何变成错误的。还有其他的例子。正如逻辑块寻址和分区位记录的 SCSI 和 ATA 世界将 BSD 文件系统设计中所有对旋转延迟的仔细计算排除在外，因此 SSD 的物理机制宁愿将可用空间排除在外获得了适用于温彻斯特光盘的智慧。

对于 SSD，设备上的可用空间量作为一个整体，即磁盘上的所有卷以及它们之间的可用空间量，对性能和寿命都有影响。SSD 没有要旋转的盘片和要查找的磁头这一事实削弱了文件需要存储在具有连续逻辑块地址的块中这一想法的基础。规则又变了。

随着固态硬盘的可用空间，建议最小量实际上是多比来自温彻斯特光盘和伯克利FFS 33年前的实验传统的10％。例如，Anand Lal Shimpi 提供 25%。由于这必须是整个设备上的可用空间，而 10% 的数字在每个单个 FFS 卷内，因此这种差异会更加复杂，因此受到分区程序是否知道要修剪所有未使用的空间的影响由分区表分配给一个有效的磁盘卷。

它也被复杂如TRIM感知文件系统驱动程序，可以修剪自由空间加剧内盘卷，而事实上，SSD制造商本身也已经分配了不同程度的保留空间，是不是偶可见outwith设备（即到主机）用于各种用途，例如垃圾收集和磨损均衡。

参考书目

• Marshall K. McKusick、William N. Joy、Samuel J. Leffler 和 Robert S. Fabry (1984-08)。 适用于 UNIX 的快速文件系统。ACM 计算机系统交易。第 2 卷第 3 期。第 181-197 页。存档于cornell.edu。
• 雷·邓肯 (1989-09)。新的高性能文件系统的设计目标和实现。 微软系统杂志。第 4 卷第 5 期。第 1-13 页。存档于 wisc.edu。
• Marshall Kirk McKusick、Keith Bostic、Michael J. Karels 和 John S. Quarterman (1996-04-30)。“伯克利快速文件系统”。4.4 BSD操作系统的设计与实现。艾迪生韦斯利专业。ISBN 0201549794。
• 丹·布里奇斯 (1996-05)。高性能文件系统内部 - 第 4 部分：碎片、磁盘空间位图和代码页。有效位。存档在电子开发人员杂志上，用于 OS/2。
• Keith A. Smith 和 Margo Seltzer (1996)。 FFS 磁盘分配策略的比较。USENIX 年度技术会议论文集。存档于 harvard.edu。
• 史蒂夫 D. 佩特 (2003)。“FFS 的性能分析”。 UNIX 文件系统：演变、设计和实现。约翰威利放大器; 儿子们。ISBN 9780471456759。
• Amir H. Majidimehr (1996)。优化 UNIX 的性能。普伦蒂斯大厅。ISBN 9780131115514。
• 比尔·卡尔金斯 (2002)。“管理文件系统”。 在 Solaris 9 中。阙出版。国际标准书号 9780735711013。
• 阿南德·拉尔·辛皮 (2012-10-04)。探索现代 SSD 中备用区域与性能一致性之间的关系。阿南德科技。
• 亨利·库克、乔纳森·埃利索普、劳拉·凯斯和安德鲁·沃特曼 (2010)。IotaFS：探索 SSD 的文件系统优化。IEEE 消费电子学报。存档于 stanford.edu。
• https://superuser.com/a/1081730/38062
• Accela Zhao (2017-04-10)。SSD 和 FTL 摘要。github.io。
• Windows 是否会修剪 SSD 上未分区（未格式化）的空间？

Answer 4

当然，驱动器本身（HDD 或 SSD 之类的）并不关心它的使用百分比，除了 SSD 能够预先为您擦除其可用空间。读取性能将完全相同，写入性能在 SSD 上可能会差一些。无论如何，在几乎已满的驱动器上写入性能并不重要，因为没有空间可以写入任何内容。

另一方面，您的操作系统、文件系统和应用程序希望您始终拥有可用空间。20 年前，应用程序通常会先检查驱动器上有多少空间，然后再尝试将文件保存在那里。今天，应用程序会在未经您许可的情况下创建临时文件，并且通常会在不这样做时崩溃或表现异常。

文件系统也有类似的期望。例如，NTFS 为 MFT 保留了一大块磁盘，但仍会向您显示此空间为空闲空间。当您填充 NTFS 磁盘超过其容量的 80% 时，您会得到MFT 碎片，这对性能有非常实际的影响。

此外，拥有可用空间确实有助于防止常规文件的碎片化。文件系统倾向于通过根据每个文件的大小为每个文件找到合适的位置来避免文件碎片化。在接近填满的磁盘上，他们将有更少的选择，因此他们将不得不做出更糟糕的选择。

在 Windows 上，您还需要有足够的磁盘空间用于交换文件，它可以在必要时增长。如果不能，您应该期待您的应用程序被强行关闭。交换空间很少确实会降低性能。

即使您的交换区具有固定大小，完全耗尽系统磁盘空间也会使您的系统崩溃和/或使其无法启动（Windows 和 Linux 类似），因为操作系统希望能够在启动期间写入磁盘。所以是的，达到 90% 的磁盘使用率应该会让你认为你的油漆着火了。在删除最近的下载以给操作系统一些磁盘空间之前，我从未见过无法正常启动的计算机。

Answer 5

对于 SSD 来说，应该有一些剩余空间，因为重写率会增加并对磁盘的写入性能产生负面影响。80% 已满可能是所有 SSD 磁盘的安全值，某些最新型号即使占用 90-95% 的容量也可以正常工作。

https://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/

Answer 6

“规则”因您的要求而异。还有一些特殊情况，例如 ZFS：“在 90% 的容量下，ZFS 从性能优化切换到基于空间的优化，这会对性能产生巨大影响。”。是的，这是ZFS 的一个设计方面......不是通过观察或轶事证据得出的。显然，如果您的 ZFS 存储池仅由 SSD 组成，这不是什么问题。然而，即使使用旋转磁盘，当您处理静态存储时，您也可以愉快地达到 99% 或 100%，并且您不需要一流的性能 - 例如，您个人最喜欢的电影收藏，它永远不会改变，并且在哪里安全第一。

接下来，btrfs - 一种极端情况：当可用空间太低（几兆字节）时，您可能会遇到不归路。不，删除文件不是一种选择，因为您不能。根本没有足够的空间来删除​​文件。btrfs 是一个 COW（写时复制）文件系统，您可以达到无法再修改元数据的地步。此时，您仍然可以向文件系统添加额外的存储空间（USB 拇指驱动器可能会起作用），然后从扩展的文件系统中删除文件，然后缩小文件系统并再次删除额外的存储空间）。同样，这是由文件系统设计引起的某些方面。

可以为您提供“真实（严重）数据”的人可能是处理“真实（严重）存储”的人。Twisty（优秀）的回答提到了在企业环境中运行的混合阵列（由大量廉价的慢速旋转磁盘、大量快速旋转磁盘、许多 SSD...组成），这些阵列在企业环境中运行，其中主要限制因素是管理员的速度能够订购升级。从 16T 到 35T 可能需要 6 个月的时间......所以你最终会得到可靠的报告，建议将你的警报设置为 50%。