Warum extrahiert GNU tar so langsam?

 (mort.coffee)
10 Punkte von xguru 2022-07-25 | 1 Kommentare | Auf WhatsApp teilen
  • Die Untersuchung begann, weil das Entpacken von 518GiB tar.gz extrem langsam wurde
  • Erklärung des Tar-Formats und Beschreibung anhand eines selbst geschriebenen schnellen Tar-Extractors

Das originale Tar-Dateiformat

  • Tar ist als Archivformat sehr ungewöhnlich
    → Es gibt keinen Archiv-Header, keinen Dateiindex für die Suche, keine Magic Bytes zur Erkennung als Tar, keinen Footer und keine Metadaten
    → In Tar gibt es nur einen einzigen Typ von Dateiobjekten
  • Dateitypen: 0 (normale Datei), 1 (Hardlink), 2 (symbolischer Link)
  • Erklärung der Struktur des 512-Byte-Headers eines Dateiobjekts
    → Die größte Einschränkung ist, dass Dateipfade nur 100 Zeichen lang sein dürfen. Außerdem ist die Dateigröße auf maximal 8GiB begrenzt

UStar-Erweiterungsdatei

  • Dateipfade sind nun bis zu 256 Zeichen lang, und es wurden neue Dateitypen hinzugefügt
  • Der Header wurde erweitert und um Magic Bytes sowie ein prefix-Feld ergänzt
  • Hinzugefügte Dateitypen: 3 (Character Device), 4 (Block Device), 5 (Verzeichnis), 6 (FIFO-Datei), 7 (zusammenhängende Datei)
  • Die Größenbegrenzung von 8GiB bleibt jedoch bestehen

Pax-Dateiformat

  • Erweiterung des Tar-Formats über das pax-CLI im Standard POSIX.1-2001
  • Entspricht UStar, ergänzt aber die Dateiformate x und g
    → Als erweiterte Header-Records gilt x nur für die nächste Datei, g hingegen für alle folgenden Dateien

GNU-Tar-Dateiformat

  • Das eigene Format ist gnu und unterscheidet sich von pax
  • Ähnlich wie pax auf UStar basierend, nutzt aber andere Methoden zur Kodierung von Pfaden und großen Dateien
    → Typ L: Die Payload des nächsten Dateiobjekts stellt file_path dar
    → Typ K: Die Payload des nächsten Dateiobjekts stellt link_path dar
    → Beide können nacheinander angewendet werden
    → Ist eine Datei größer als 8GiB, wird das High Bit des ersten Zeichens von file_size gesetzt. Der Rest der Zeichenkette wird dann als Base-256 geparst (95-Bit-Integer)

Warum dekomprimiert GNU tar so langsam?

  • Wenn im Header einer Datei ein Wert wie file_path="../hello.txt" steht, entsteht ein Sicherheitsproblem. Es ist jedoch nicht einfach, das zu verhindern
  • GNU tar erstellt bei link_path mit .. einen Platzhalter und verarbeitet ihn verzögert
  • Bei Hardlinks ohne .. würde man sie eigentlich direkt anlegen wollen, doch wegen bereits vorhandener Platzhalter ist das nicht möglich
  • Um also einen Hardlink anzulegen, muss zunächst vollständig geprüft werden, ob es sich um einen verzögerten Link handelt; falls ja, muss auch der neue Link verzögert verarbeitet werden
    → Für alle Hardlinks müssen also verzögerte Links durchsucht werden. Warum auch immer, in der Praxis geschieht diese Suche sogar zweimal
  • Im Tar des Autors gab es über 800.000 Links mit .. und mehr als 5,4 Millionen Hardlinks, weshalb das Entpacken langsam wurde
  • Um das zu vermeiden, sollte man tar die Option --absolute-paths oder -P hinzufügen
    → Diese Option speichert absolute Pfade und weist .. zurück
    → Mit der Option -P wird also der Mechanismus für verzögerte Verlinkung deaktiviert

Verwandte Beiträge