Frage Gibt es einen intelligenteren tar oder cpio, um eine im Archiv gespeicherte Datei effizient abzurufen?


ich benutze tar eine Gruppe sehr großer (Multi-GB) zu archivieren bz2 Dateien.

Wenn ich benutze tar -tf file.tar Um die Dateien im Archiv aufzulisten, dauert dies sehr lange (~ 10-15 Minuten).

Gleichfalls, cpio -t < file.cpio dauert genauso lange, plus oder minus ein paar Sekunden.

Dementsprechend, eine Datei aus einem Archiv (über tar -xf file.tar myFileOfInterest.bz2 zum Beispiel) ist so langsam.

Gibt es eine Archivierungsmethode, die einen leicht verfügbaren "Katalog" mit dem Archiv bereithält, so dass eine einzelne Datei innerhalb des Archivs schnell abgerufen werden kann?

Zum Beispiel eine Art Katalog, der einen Zeiger auf ein bestimmtes Byte im Archiv speichert, sowie die Größe der Datei, die abgerufen werden soll (sowie alle anderen Dateisystem-spezifischen Einzelheiten).

Gibt es ein Werkzeug (oder ein Argument dafür)? tar oder cpio) das ermöglicht den effizienten Abruf einer Datei im Archiv?


18
2017-08-27 23:26


Ursprung




Antworten:


tar (und cpio und afio und pax und ähnliche Programme) sind Stream-orientierte Formate - sie sollen direkt auf ein Band gestreamt oder in einen anderen Prozess geleitet werden. während es theoretisch möglich wäre, einen Index am Ende der Datei / des Streams hinzuzufügen, weiß ich keine Version, die das tut (es wäre jedoch eine nützliche Verbesserung)

Es hilft nicht bei Ihren vorhandenen tar- oder cpio-Archiven, aber es gibt ein anderes Werkzeug, dar ("disk archive"), das Archivdateien erstellt, die einen solchen Index enthalten und Ihnen schnellen direkten Zugriff auf einzelne Dateien innerhalb des Archivs geben können .

Wenn es nicht in Ihrem unix / linux-dist enthalten ist, finden Sie es unter:

http://dar.linux.free.fr/


12
2017-08-28 01:07



Gibt es eine Möglichkeit, eine Extraktion auf die Standardausgabe zu übertragen? Es sieht so aus, als gäbe es eine Möglichkeit, ein Archiv aus der Standardeingabe zu machen, aber nicht (zumindest nicht direkt), um es zur Standardausgabe zu extrahieren. Aus der Dokumentation geht nicht hervor, ob es einen Weg gibt, dies zu tun. Weißt du, wie das erreicht werden könnte? - Alex Reynolds
Nein, weiß es nicht. Ich benutze den Dar nicht wirklich selbst ... ich weiß nur, dass es existiert. Ich bin glücklich genug mit tar, und tendieren dazu, nur Textdateien zu erstellen, die den Inhalt für große Tar-Dateien auflisten, die ich später suchen könnte. Sie können dies gleichzeitig mit dem Erstellen des tar-Archivs tun, indem Sie die Option v zweimal verwenden (z. B. "tar cvvjf /tmp/foo.tar.bz2 / pfad / zu / backup> /tmp/foo.txt"). - cas


Sie können SquashFS für solche Archive verwenden. Es ist

  • entworfen, um unter Verwendung eines Sicherungstreibers zugegriffen zu werden (obwohl eine traditionelle Schnittstelle existiert)
  • komprimiert (je größer die Blockgröße, desto effizienter)
  • im Linux-Kernel enthalten
  • speichert UIDs / GIDs und Erstellungszeit
  • Endianess-bewusst, daher ziemlich tragbar

Der einzige Nachteil, den ich kenne, ist, dass es schreibgeschützt ist.

http://squashfs.sourceforge.net/ http://www.tldp.org/HOWTO/SquashFS-HOWTO/whatis.html


9
2017-12-30 17:31





Während es keinen Index speichert, star angeblich schneller sein als tar. Außerdem unterstützt es längere Dateinamen und bietet eine bessere Unterstützung für Dateiattribute.

Wie Sie sicher wissen, dauert das Dekomprimieren der Datei Zeit und würde wahrscheinlich einen Faktor für die Geschwindigkeit der Extraktion darstellen, selbst wenn ein Index vorhanden wäre.

Bearbeiten: Vielleicht möchten Sie auch einen Blick darauf werfen xar. Es hat einen XML-Header, der Informationen über die Dateien im Archiv enthält.

Von der referenzierten Seite:

Der XML-Header von Xar erlaubt es, beliebige Metadaten über Dateien zu enthalten, die im Archiv enthalten sind. Zusätzlich zu den Metadaten der Standard-Unix-Datei wie der Größe der Datei und den Änderungs- und Erstellungszeiten kann xar Informationen wie ext2fs und hfs-Dateibits, Unix-Flags, Verweise auf erweiterte Attribute, Mac OS X Finder-Informationen und Mac OS speichern X Ressourcen-Forks und Hashes der Dateidaten.


6
2017-08-28 01:04



+1, um mich auf ein nützliches klingendes Werkzeug aufmerksam zu machen, von dem ich noch nie zuvor gehört hatte. - cas
Link von star ist unten...... - Pacerier


Das einzige Archivformat, von dem ich weiß, dass es einen Index speichert, ist ZIP, weil ich beschädigte Indizes mehr als einmal rekonstruieren musste.


2
2017-08-28 00:53





Thorbjørn Ravn Anderser ist richtig. GNU tar erstellt standardmäßig "suchbare" Archive. Aber es verwendet diese Information nicht, wenn es diese Archive liest, wenn die Option -n nicht angegeben ist. Mit -n Option habe ich gerade 7GB Datei von 300GB Archiv in der Zeit extrahiert, um 7GB zu lesen / schreiben. Ohne -n ​​dauerte es mehr als eine Stunde und ergab kein Ergebnis.

Ich bin mir nicht sicher, wie sich das auf die Komprimierung auswirkt. Mein Archiv wurde nicht komprimiert. Komprimierte Archive sind nicht "suchbar", da der aktuelle (1.26) GNU-tar die Komprimierung in ein externes Programm verlagert.


2
2017-10-17 12:56



nach der Tear-Man-Seite man7.org/linux/man-pages/man1/tar.1.html, GNU tar wird standardmäßig das suchbare Format beim Schreiben verwenden, und wenn das Archiv suchbar ist, wird es beim Lesen (für Liste oder Auszug) verwenden. Wenn Sie GNU tar verwenden und das Problem weiterhin auftritt, sollten Sie einen Fehlerbericht mit GNU einreichen. - Brian Minton
Wenn ich das Handbuch richtig lese, sagt es nie, dass es irgendeine Art von Index hat und kann zu jeder Datei innerhalb des Archivs springen, wenn der Dateiname angegeben wird. --seek bedeutet nur, dass das zugrunde liegende Medium suchbar ist. Wenn es von Anfang an gelesen wird, kann es das Lesen von Dateiinhalten überspringen, aber es muss immer noch Anfangseinträge lesen. Das heißt, wenn Sie ein Archiv mit 1M-Dateien haben und Sie versuchen, das letzte mit --no-seek zu extrahieren, müssen Sie den Inhalt aller Dateien lesen; Mit --seek müssen Sie nur 1M Header lesen, einen für jede Datei, aber es ist immer noch super langsam. - icando


Es indiziert nicht, dass ich weiß, aber ich verwende dump & restore mit großen Dateien, und die Navigation im interaktiven Modus zur Auswahl zufälliger Dateien ist sehr schnell.


1
2017-08-28 02:44





Sie können das 7z (7zip) Archiv / Kompressionsformat verwenden, wenn Sie Zugriff auf die p7zip-full Paket.

Unter Ubuntu können Sie diesen Befehl verwenden, um es zu installieren:

$ sudo apt-get install p7zip-full

So erstellen Sie ein Archiv, das Sie verwenden können 7z a <archive_name> <file_or_directory> und wenn Sie die Dateien nicht komprimieren möchten und sie nur so "wie" speichern möchten, können Sie das verwenden -mx0 Option wie:

$ 7z a -mx0 myarchive.7z myfile.txt

Creating archive myarchive.7z

Sie können die Dateien dann mit extrahieren 7z e:

$ 7z e myarchive.7z

Processing archive: myarchive.7z
Extracting  myfile.txt

Oder Sie können den Index des Archivs mit dem 7z l das ist praktisch zum Suchen mit grep:

$ 7z l myarchive.7z | grep

2014-07-08 12:13:39 ....A            0            0  myfile.txt

Dies ist auch der t Möglichkeit, Integrität zu testen, u Hinzufügen / Aktualisieren einer Datei zum Archiv und d um eine Datei zu löschen.

WICHTIGE NOTIZ
Tun nicht Verwenden Sie das 7zip-Format für Linux-Dateisystem-Backups, da es den Besitzer und die Gruppe der enthaltenen Dateien nicht speichert.


1
2017-07-08 02:50





Ich glaube, dass GNU tar in der Lage ist zu tun, was Sie wollen, aber ich kann keine definitive Ressource finden, die das sagt.

In jedem Fall benötigen Sie ein Archivierungsformat mit einem Index (da Sie damit tun können, was Sie wollen). Ich glaube nicht, dass ZIP-Dateien leider so groß werden können.


0
2017-08-28 18:11



ZIP-Dateien können wachsen groß. - Pacerier
Wenn ich das Handbuch richtig lese, sagt es nie, dass es irgendeine Art von Index hat und kann zu jeder Datei innerhalb des Archivs springen, wenn der Dateiname angegeben wird. --seek bedeutet nur, dass das zugrunde liegende Medium suchbar ist. Wenn es von Anfang an gelesen wird, kann es das Lesen von Dateiinhalten überspringen, aber es muss immer noch Anfangseinträge lesen. Das heißt, wenn Sie ein Archiv mit 1M-Dateien haben und Sie versuchen, das letzte mit --no-seek zu extrahieren, müssen Sie den Inhalt aller Dateien lesen; Mit --seek müssen Sie nur 1M Header lesen, einen für jede Datei, aber es ist immer noch super langsam. - icando
@Pacerier Nach meinem Verständnis erlaubt das ZIP64-Format sehr große Dateien, das originale ZIP-Format jedoch nicht. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen, Eine Single 4GB Datei ist groß Kumpel. - Pacerier