正如上面的问题，7zip（更具体地说是 Linux 上的 p7zip）在测试档案时会占用磁盘空间吗？由于我只有一个 2TB 的驱动器可以使用，并且每个档案的大小都在 800GB-1TB 之间，所以我想同时测试 2 个档案，而不是只测试一个。
7zip 官方文档没有提及测试时的磁盘使用情况。
答案1
不应该。（但有可能）
为了在提取档案时验证其中的数据是否正确，每个文件或数据块都会有一个与之关联的 CRC 或错误检测码。
从效率的角度来看，在解压文件时进行错误检查非常有意义前将数据写入磁盘。否则，您将浪费宝贵的资源从存档中读取数据，将其写入磁盘，然后重新读取磁盘上的数据以进行错误检查。对于大型存档或内存受限的系统，这可能会使解压文件所需的时间增加一倍，这是不可接受的。在这种情况下，我假设磁盘读写是该过程中最慢的部分。
如果在写入之前进行检查，则可以有效地将存档流式传输到解压缩器、错误检查算法，然后输出到磁盘，并假设磁盘子系统知道它在做什么。任务完成。
通过这种方式，“测试”存档成为一项免费操作。您遵循与解压缩完全相同的步骤，但您只是丢弃数据而不将其写入磁盘。
我强烈希望这是它的工作方式，因为仅仅为了测试档案而将所有内容写入磁盘似乎很疯狂，而且不会比“真正”解压数据更快。“测试”速度更快意味着至少跳过了一个步骤，最有可能是将数据写入磁盘。
答案2
不，不是——至少 19.00 版本不是。
在固态硬盘上并行测试多个文件效果很好，但通常会降低机械硬盘的性能——需要进行大量搜索才能并行读取多个档案。因此，可以提出以下建议：
在固态硬盘（NVMe 或 SATA SSD）上测试档案时，启动与核心数量相同的进程（如果可以）。
在同一机械驱动器（或机械 RAID 卷）上测试档案时，启动一个或最多两个进程。
在 USB 驱动器上测试档案时，结果会有所不同。
遗憾的是，大多数常见的 USB“笔式驱动器”或“棒”即使在读取时也非常慢 - 即远未达到 USB 接口带宽饱和。一些此类驱动器在同时访问驱动器中几个不同区域的数据时甚至会变得更慢。这是由于磁盘控制器中的 RAM 有限造成的。控制器无法一次性将访问整个驱动器所需的所有元数据装入 RAM 中，最终会在更改驱动器上的读取区域时重新读取闪存介质中的元数据，通常必须遵循链接链才能找到它。即使闪存布局允许，驱动器通常也不会并行读取此类元数据，并且通常还使用速度很慢的专用代码路径来实现。
解决这个问题的唯一可靠方法是进行带宽测试。假设您必须验证档案、、、a和，它们b的大小顺序大致相同。它们需要按大小降序排列。首先，计算验证时间，并计算带宽。然后并行验证和，并计算这些带宽。只要它们的总和大于，您就会获得性能。然后并行验证和并计算这些带宽。只要它们的总和大于，您就会获得性能。依此类推。最终，您将达到总带宽与上一次测试相比有所下降的流数。然后继续使用之前较少数量的流验证剩余的档案。cdefaBW_a = time_a / size_abcsum_BW_bcBW_adefsum_BW_defsum_BW_bc
这种方法可以应用于任何驱动器，但机械驱动器的性能下降幅度非常大，可能会过度影响验证过程的整体性能。因此，当知道并行测试的带宽小于前一步带宽的 90% 时，应终止并行测试。您可以通过在测试运行的每一秒重新计算带宽，并在带宽低于截止点时终止测试来实现这一点。