我Pages在 Ubuntu 服务器上有一个名为 220 万个 HTML 文件（约 80 GB）的目录。我使用以下命令使用 7-Zip 对其进行压缩：
7z a -mx=9 Pages.7z Pages
压缩大约需要5-6个小时（似乎有点过长）。压缩后大小约为2.3 GB。
然后我将其下载到我的主计算机（Ubuntu、Intel® Xeon® CPU E5-1650 v2 @ 3.50GHz）。每次我尝试提取时，它都会以令人失望但可以接受的速度开始，但随着提取速度的加快，速度会慢得像爬行一样（运行了一夜，当我醒来时，它每分钟处理大约 300 个文件）。
然而，在我的 Windows 机器（Intel® Xeon® CPU E5-2687W @ 3.10GHz 3.10 GHz，这只是稍微好一点的机器上），我在 15-20 分钟内提取了整个目录。它也显然利用了多个处理器，这我无法在 Ubuntu 上使用 7-Zip。
显然我不能、也不应该花几天时间进行拔牙。
我的感觉是，这与我不了解 Ubuntu（我是一个正在恢复的 Windows 用户）或我的文件系统有关，而不是 7-Zip。任何帮助将不胜感激。
我的主机使用ext4文件系统，我的7-Zip版本是9.20：
7-Zip [64] 9.20 p7zip 版本 9.20（区域设置=en_US.UTF-8、Utf16=on、HugeFiles=on、12 个 CPU）
更新：
我应该澄清一下，我的主 Ubuntu 安装上实际上有一个驱动器是 ext4（我的 ssd），尽管我还有另一个驱动器是 ntfs（我想我记得 Ubuntu 在安装过程中推荐了这个，也许是因为我设置了它）作为raid阵列）。无论我在哪一个地方工作，随着时间的推移，速度变慢的问题都会发生。
按照评论中的建议，我使用 Windows 机器解压压缩文件，用 4096 个子目录重组目录，然后重新压缩它（尽管这次我使用默认压缩级别而不是最大压缩级别，并指定了 lzma2）。然后我将其转移到我的 Ubuntu 机器（特别是 ext4 SSD）并解压缩。正如我所期望的那样，它工作得非常好——非常快。
但是，正如另一位评论者指出的那样，这里问题的一部分可能只是我的 Ubuntu 机器上的驱动器没有被索引（它们在 Windows 上被索引了），并且如果我确实索引了（我一直想这样做），我可能根本不需要重组目录。我目前正在尝试弄清楚如何成功且安全地做到这一点……并将报告任何有用的结果。
我还尝试使用 python 重建 Ubuntu 机器上已有的目录，但速度慢得不合理。也许这是一个Python问题，而不是Linux/ext4/ntfs，或者它也可能与索引有关，或者可能是b/c源目录在一个目录中有220万个文件......：
for fileName in series:
if not os.path.exists('[...]/Pages2/' + fileName[:3] + '/' + fileName):
shutil.copy('[...]/Pages/' + fileName, '[...]/Pages2/' + fileName[:3] + '/' + fileName)
答案1
当我阅读 XZ 的维基百科条目时，我终于找到了真正的答案（https://en.wikipedia.org/wiki/Xz）：
人们可以将 xz 视为 7-Zip 程序的精简版本。 xz 有自己的文件格式，而不是使用的 .7z 格式7-Zip（缺乏对类 Unix 文件系统元数据的支持[2]）。
事实上，在 Ubuntu 的 NTFS 或 EXT-4 上，在一个目录中拥有数百万个小文件似乎是可以的（但由于其他原因，可能不建议这样做）。我的文件系统上的索引也没有任何问题。 7zip 在尝试提取大型目录时速度变慢的原因与 7zip 的编写者不太关心 Linux/Unix 用户有关。
这确实让我怀疑编写 Nautilus 的人是否同样蔑视 Linux 用户……b/c 它也确实不喜欢包含大量文件的目录，而 Windows 资源管理器对此没有任何问题。
答案2
你说的是一个包含 220 万个文件的目录吗？当您处理这么多文件时，Ext 文件系统会变得很慢。