目前，我正在使用ArchiveMount一个123,000 kb的归档文件，其中包含超过300万个文件。到目前为止，它已经安装了5个多小时，但仍未完成。

有挂载.tar.gz文件的更好方法吗？我正在尝试挂载到文件夹，并且解压缩后需要花费一些时间。我什至不需要写模式，仅只读就足够了。

您还可以创建一个压缩的squashfs图像

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

为此，您需要解压缩tar.gz archvie。

优点还在于图像比gz具有更好的容错性。

这里的问题是格式，TAR（磁带存档）格式设计用于顺序访问，而不是随机访问。gzip是对tar的很好补充，因为它是基于流的压缩格式，也不适合随机访问。

因此，不直接与压缩块交互的高级工具将在每次需要读取任何内容时都必须解析整个文件，首先要获取文件列表，然后缓存可能会失效并再次读取它，然后对于您复制的每个文件，它可能会再次读取它。您可以制作一个能够记住每个文件位置以及需要解压缩才能获取文件的块的工具，但是似乎很少有人对此感到烦恼。

如果您希望这样做更快，请执行tar tzf file.tar.gz > filelist，在vim，gedit或其他文件中打开该文件列表，删除不需要的文件行，保存，然后使用提取它们tar xzf file.tar.gz -T filelist -C extracted/。

要随机访问压缩文件，您应该使用带有posix扩展名的zip（rar）或dru8274建议使用的squashfs，甚至使用启用了压缩功能的ZFS，如果使用btrfs在阅读时已经进行了压缩，则应该使用btrfs。

我写了一个更快的替代书ratarmount，它对我有用，因为这个问题一直困扰着我。

您可以像这样使用它：

pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level

完成后，您可以像任何FUSE装载一样卸载它：

fusermount -u mount-folder

为什么它比archivemount快？

这取决于您的测量。

这是内存占用量和首次安装所需时间的基准，以及简单cat <file-in-tar>命令和简单find命令的访问时间。

创建了包含每个1k文件的文件夹，并且文件夹的数量有所不同。

左下方的图显示误差线，指示cat <file>10个随机选择的文件的最小和最大测量时间。

档案搜寻时间

杀手级比较是cat <file>完成所需的时间。出于某种原因，对于归档安装，它与TAR文件大小（每个文件大约字节x文件数）成线性比例关系，而在固定时间中保持不变。这使得archivemount看起来根本不支持搜索。

对于压缩的TAR文件，这一点尤其明显。 cat <file>挂载整个.tar.bz2文件所需的时间是原来的两倍！例如，具有10k个empty（！）文件的TAR用archivemount挂载需要2.9s的时间，但是根据所访问的文件的不同，tar的访问cat时间在3ms到5s之间。花费的时间似乎取决于TAR中文件的位置。TAR末尾的文件需要更长的时间才能找到；指示模拟了“搜索”并且正在读取文件之前TAR中的所有内容。

获取文件内容所花费的时间是安装整个TAR所花费时间的两倍以上，这本身就是意外的。至少，它应该在与安装相同的时间内完成。一种解释是，该文件被多次模拟查找，甚至可能三次。

Ratarmount看似总是花费相同的时间来获取文件，因为它支持真正的查找。对于bzip2压缩的TAR，它甚至搜索bzip2块，其地址也存储在索引文件中。从理论上讲，唯一应随文件数量缩放的部分是索引中的查找，并且应按O（log（n））缩放，因为它是按文件路径和名称排序的。

内存占用

通常，如果TAR中有超过20k个文件，则ratarmount的内存占用量会较小，因为索引是在创建时写入磁盘的，因此系统上的内存占用量约为30MB。

gzip解码器后端是一个小例外，由于gzip变大，出于某种原因，它需要更多的内存。此内存开销可能是在TAR内部进行搜索所需的索引，但是由于我没有编写该后端，因此需要进一步调查。

相反，只要安装了TAR，archivemount就会将整个索引（例如2M文件的4GB）完全保留在内存中。

安装时间

我最喜欢的功能是Ratarmount，它能够挂载TAR，而不会在随后的任何尝试中明显延迟。这是因为将文件名映射到元数据和TAR内部位置的索引被写入到TAR文件旁边创建的索引文件中。

安装所需的时间在archivemount中表现得有些奇怪。从大约2万个文件开始，相对于文件数量，它开始按比例缩放，而不是线性缩放。这意味着从大约4M个文件开始，ratarmount开始比archivemount快得多，即使对于较小的TAR文件而言，其速度要慢10倍！再说一次，对于较小的文件，挂载tar是1s还是0.1s无关紧要（第一次）。

bz2压缩文件的挂载时间始终是最可比的。这很可能是因为它受bz2解码器的速度限制。拉塔芒特的速度大约要慢2倍。我希望通过在不久的将来对bz2解码器进行并行处理来使拉特芒特无疑是赢家，即使对于我使用了8年的系统，其速度也可以提高4倍。

是时候获取元数据了

当仅列出findTAR内部的所有文件时（发现每个文件似乎也调用stat !?），对于所有测试案例，ratarmount的速度比archivemount慢10倍。我希望将来能对此有所改善。但是目前，由于使用Python和SQLite而不是纯C程序，这看起来像是一个设计问题。

这不会涵盖所有用例，因为它将使用限制为文本编辑器。但是，如果您只关心读取访问，则在某些情况下可能会有所帮助。vim，当在tarball上运行时，将向您显示存档的内容层次结构（类似于在目录上运行时它将显示文件层次结构的方式）。通过选择列表中的文件之一，它将在只读缓冲区中打开所选文件。

同样，这不一定提供对图像或其他媒体的访问，但是如果您只需要查看内容或仅访问基于文本的文件，那么这将很有帮助。

注意：这不适用于所有存档格式。

我的方法。如果外部USB驱动器或具有足够空间的外部/辅助HDD驱动器上具有足够的可用磁盘空间，则可以考虑仅提取.tar.gz文件。认为您可能不希望主系统磁盘上有300万个文件，因为这可能会减慢速度。我建议在这种情况下，外部磁盘具有一个可以轻松处理大量文件的文件系统：考虑使用ReiserFS，ext4（带有dir_index选项），XFS或BtrFS。提取可能要花1-2个小时，但您可以在此期间享用午餐或过夜。当您回来时，访问提取的文件应该很有效。