現時点ではArchiveMount、300万個を超えるファイルを含む123,000 kbのアーカイブをマウントするために使用しています。これまでのところ、5時間以上マウントされており、まだ終了していません。

.tar.gzファイルをマウントするより良い方法はありますか？フォルダーにマウントしようとしていますが、非圧縮には数ギガかかります。書き込みモードも必要ありません。読み取り専用で十分です。

圧縮されたsquashfsイメージを作成することもできます

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

これを行うには、tar.gz archvieを抽出する必要があります。

また、利点は、イメージの耐障害性がgzより優れていることです。

この問題が私を悩ませ続けたので、私はより速い代替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>完了するまでにかかる時間です。何らかの理由で、これは、artarmountで一定の時間でありながら、archivemountのTARファイルサイズ（ファイルあたりのバイト数xファイル数）に比例してスケーリングします。これにより、archivemountはシークをまったくサポートしていないように見えます。

圧縮されたTARファイルの場合、これは特に顕著です。 cat <file>.tar.bz2ファイル全体をマウントする場合の2倍以上の時間がかかります！たとえば、10kのempty（！）ファイルを含むTARは、archivemountでマウントするのに2.9秒かかりますが、アクセスされるファイルによってcatは、3msから5秒のアクセスがかかります。要する時間は、TAR内のファイルの位置に依存するようです。TARの最後にあるファイルはシークに時間がかかります。「シーク」がエミュレートされ、ファイルが読み込まれる前にTARのすべての内容がエミュレートされることを示します。

TAR全体をマウントすること自体では、ファイルの内容の取得に2倍以上の時間がかかることがあります。少なくとも、マウントと同じ時間で終了するはずです。1つの説明は、ファイルが複数回、おそらく3回もエミュレートされていることです。

Ratarmountは、真のシークをサポートするため、ファイルを取得するのに常に同じ時間を要するようです。bzip2で圧縮されたTARの場合、bzip2ブロックもシークします。このブロックのアドレスもインデックスファイルに保存されます。理論的には、ファイルの数に応じてスケーリングする必要があるのは、インデックス内のルックアップのみであり、ファイルパスと名前でソートされるため、O（log（n））でスケーリングする必要があります。

メモリフットプリント

一般に、TAR内に20kを超えるファイルがある場合、ratarmountのメモリフットプリントは小さくなります。これは、インデックスが作成時にディスクに書き込まれるため、システム上で約30MBの一定のメモリフットプリントがあるためです。

小さな例外はgzipデコーダバックエンドです。gzipが大きくなると、何らかの理由でより多くのメモリが必要になります。このメモリオーバーヘッドは、TAR内でシークするために必要なインデックスかもしれませんが、そのバックエンドを記述しなかったため、さらなる調査が必要です。

対照的に、archivemountは、TARがマウントされている限り、インデックス全体（2Mファイルの場合は4GBなど）を完全にメモリに保持します。

実装時間

私のお気に入りの機能は、ratarmountがTARをマウントし、その後の試行を著しく遅らせることです。これは、ファイル名をメタデータとTAR内の位置にマップするインデックスが、TARファイルの隣に作成されたインデックスファイルに書き込まれるためです。

マウントに必要な時間は、archivemountで奇妙な動作をします。およそ2万個のファイルから開始し、ファイル数に対して線形ではなく二次的にスケーリングを開始します。これは、約4Mのファイルから開始すると、小さなTARファイルの場合は最大10倍遅くても、ratarmountはarchivemountよりもはるかに高速になることを意味します。繰り返しますが、小さいファイルの場合、tarをマウントするのに1秒か0.1秒かは問題ではありません（初回）。

bz2圧縮ファイルのマウント時間は、常に最も類似しています。これは、bz2デコーダーの速度に制約されるため、非常に可能性が高いです。Ratarmountは、ここでは約2倍遅くなります。近い将来、bz2デコーダーを並列化することで、明確な勝者になり、8年前のシステムでも4倍の高速化を実現できるようになることを願っています。

メタデータを取得する時間

findTAR内のすべてのファイルを単純に一覧表示する場合（findは各ファイルに対してstatを呼び出すようです！？）、すべてのテスト済みケースのratarmountはarchivemountより10倍遅いです。私は将来これを改善したいと思っています。しかし現在、純粋なCプログラムの代わりにPythonとSQLiteを使用しているため、設計上の問題のように見えます。

ここでの問題は形式にあります。TAR（Tape ARchive）形式は、ランダムアクセスではなくシーケンシャルアクセス用に設計されています。また、gzipはストリームベースの圧縮形式であり、ランダムアクセス用でもないため、tarを補完します。

したがって、圧縮ブロックと直接対話しない高レベルのツールは、何かを読み取る必要があるたびにファイル全体を解析する必要があります。最初にファイルのリストを取得し、次にキャッシュが無効になり、再度読み取ります、そしてコピーした各ファイルについて、それは再びそれを読み通すかもしれません。あなたはできる各ファイルの位置、およびどのようなブロック、それはそれを得るために解凍する必要がありますが、いくつかのことを気にしているようですが覚えているツールを作ります。

これをもっと速くしたい場合は、a tar tzf file.tar.gz > filelistを実行し、vim、geditなどでそのファイルリストを開き、不要なファイルの行を削除し、保存してからで抽出しますtar xzf file.tar.gz -T filelist -C extracted/。

圧縮ファイルへのランダムアクセスを取得するには、おそらくzipをposix拡張、rar、またはdru8274が示唆するように、squashfs、または圧縮をオンにしたZFSを使用するか、btrfsが読み取り時に機能するように圧縮されている場合はbtrfsを使用する必要があります。

これは、使用をテキストエディターに制限するため、すべてのユースケースをカバーするわけではありません。ただし、読み取りアクセスのみに関心がある場合は、状況によっては役立つことがあります。vim、tarballで実行すると、アーカイブのコンテンツ階層が表示されます（ディレクトリで実行した場合のファイル階層の表示方法と同様）。リスト内のファイルのいずれかを選択すると、選択したファイルが読み取り専用バッファーで開かれます。

繰り返しますが、これは必ずしも画像や他のメディアへのアクセスを提供するわけではありませんが、必要なのはコンテンツを見るか、テキストベースのファイルにアクセスするだけであれば、これは役立つはずです。

注：これはすべてのアーカイブ形式で機能するわけではありません。

私のアプローチ。外部USBドライブまたは外部/セカンダリHDDドライブに十分な空き容量がある十分な空きディスク容量がある場合は、.tar.gzファイルを抽出することを検討してください。メインシステムディスクに300万個のファイルが必要になるとは思わないでしょう。この場合の外部ディスクには、膨大な数のファイルを簡単に処理できるファイルシステムを用意することをお勧めします。ReiserFS、ext4（dir_indexオプション付き）、XFS、またはBtrFSなどです。抽出に1〜2時間かかる可能性がありますが、その間に昼食を取るか、一晩実行することができます。戻ったとき、抽出されたファイルへのアクセスはパフォーマンスが高いはずです。