Ich habe einen schnelleren alternativen Ratarmount geschrieben , der "für mich funktioniert", weil mich dieses Problem immer wieder nervt.
Du kannst es so benutzen:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Wenn Sie fertig sind, können Sie es wie jedes FUSE-Mount aushängen:
fusermount -u mount-folder
Warum ist es schneller als Archivierung?
Es kommt darauf an, was Sie messen.
Hier finden Sie eine Benchmark des Speicherbedarfs und der erforderlichen Zeit für die erste Bereitstellung sowie der Zugriffszeiten für einen einfachen cat <file-in-tar>
Befehl und einen einfachen find
Befehl.
Ordner mit jeweils 1k Dateien wurden erstellt und die Anzahl der Ordner variiert.
Das untere linke Diagramm zeigt Fehlerbalken, die die minimale und maximale gemessene Zeit cat <file>
für 10 zufällig ausgewählte Dateien angeben .
Zeit für Dateisuche
Der Killervergleich ist die Zeit, die benötigt wird, um cat <file>
fertig zu werden. Aus irgendeinem Grund skaliert dies linear mit der Größe der TAR-Datei (ca. Bytes pro Datei x Anzahl der Dateien) für die Archivierung, während die Zeit in ratarmount konstant ist. Dadurch sieht es so aus, als würde ArchiveMount das Suchen überhaupt nicht unterstützen.
Bei komprimierten TAR-Dateien fällt dies besonders auf.
cat <file>
dauert mehr als doppelt so lange wie das Mounten der gesamten .tar.bz2-Datei! Zum Beispiel benötigt die TAR mit 10k leeren (!) Dateien 2,9 Sekunden, um sie mit archivemount zu laden. Abhängig von der Datei, auf die zugegriffen wird, cat
dauert der Zugriff mit zwischen 3 ms und 5 Sekunden. Die dafür benötigte Zeit scheint von der Position der Datei innerhalb der TAR abzuhängen. Die Suche nach Dateien am Ende der TAR dauert länger. Dies zeigt an, dass der "Suchlauf" emuliert ist und alle Inhalte in der TAR vor dem Lesen der Datei gelesen werden.
Das Abrufen des Dateiinhalts kann mehr als doppelt so lange dauern wie das Mounten der gesamten TAR. Zumindest sollte es in der gleichen Zeit wie die Montage beendet sein. Eine Erklärung wäre, dass die Datei mehr als einmal emuliert gesucht wird, vielleicht sogar dreimal.
Anscheinend benötigt Ratarmount immer die gleiche Zeit, um eine Datei abzurufen, da sie die echte Suche unterstützt. Bei bzip2-komprimierten TARs wird sogar nach dem bzip2-Block gesucht, dessen Adressen ebenfalls in der Indexdatei gespeichert sind. Theoretisch ist der einzige Teil, der mit der Anzahl der Dateien skaliert werden sollte, die Suche im Index und der Teil, der mit O (log (n)) skaliert werden sollte, da er nach Dateipfad und Name sortiert ist.
Speicherbedarf
Wenn Sie mehr als 20.000 Dateien in der TAR haben, ist der Speicherbedarf von ratarmount im Allgemeinen geringer, da der Index beim Erstellen auf die Festplatte geschrieben wird und daher auf meinem System einen konstanten Speicherbedarf von ca. 30 MB aufweist.
Eine kleine Ausnahme ist das gzip-Decoder-Backend, das aus irgendeinem Grund mehr Speicher benötigt, wenn der gzip größer wird. Dieser Speicheraufwand ist möglicherweise der Index, der für die Suche innerhalb der TAR erforderlich ist. Weitere Untersuchungen sind jedoch erforderlich, da ich dieses Backend nicht geschrieben habe.
Im Gegensatz dazu speichert archivemount den gesamten Index, z. B. 4 GB für 2 Millionen Dateien, vollständig im Speicher, solange die TAR bereitgestellt ist.
Montagezeit
Mein Lieblingsfeature ist ratarmount, um den TAR bei jedem weiteren Versuch ohne merkliche Verzögerung zu mounten. Dies liegt daran, dass der Index, der die Dateinamen den Metadaten und der Position innerhalb der TAR zuordnet, in eine Indexdatei geschrieben wird, die neben der TAR-Datei erstellt wird.
Die benötigte Zeit für das Mounten verhält sich im Archiv etwas seltsam. Ab ca. 20.000 Dateien beginnt die Skalierung quadratisch statt linear in Bezug auf die Anzahl der Dateien. Dies bedeutet, dass ab ungefähr 4 Millionen Dateien Ratarmount viel schneller als Archivmount ist, obwohl es für kleinere TAR-Dateien bis zu 10-mal langsamer ist! Andererseits ist es für kleinere Dateien unwichtig, ob es 1s oder 0.1s dauert, um den Teer zu mounten (das erste Mal).
Die Ladezeiten für bz2-komprimierte Dateien sind zu allen Zeiten am besten vergleichbar. Dies ist sehr wahrscheinlich, weil es an die Geschwindigkeit des bz2-Decoders gebunden ist. Ratarmount ist hier etwa 2x langsamer. Ich hoffe, ratarmount in naher Zukunft zum klaren Sieger zu machen, indem ich den bz2-Decoder parallelisiere, was sogar für mein 8-jähriges System eine vierfache Beschleunigung bringen könnte.
Es ist Zeit, Metadaten abzurufen
Wenn Sie einfach alle Dateien mit find
innerhalb der TAR auflisten (find scheint auch stat für jede Datei aufzurufen !?), ist ratarmount für alle getesteten Fälle 10x langsamer als archivemount. Ich hoffe, dies in Zukunft verbessern zu können. Derzeit sieht es jedoch nach einem Designproblem aus, da Python und SQLite anstelle eines reinen C-Programms verwendet werden.