Wie oben gefragt: Benötigt 7zip (genauer gesagt p7zip unter Linux) Speicherplatz beim Testen von Archiven? Da ich nur mit einem 2-TB-Laufwerk arbeiten kann und jedes Archiv zwischen 800 GB und 1 TB groß ist, dachte ich daran, 2 Archive gleichzeitig zu testen, statt nur eines.
In der offiziellen 7zip-Dokumentation wird nichts über die Festplattennutzung während des Tests erwähnt.
Antwort1
Das sollte nicht der Fall sein. (Aber es könnte sein)
Um beim Extrahieren zu überprüfen, ob die Daten in einem Archiv korrekt sind, wird jeder Datei oder jedem Datenblock ein CRC- oder Fehlererkennungscode zugeordnet.
Beim Dekomprimieren einer Datei ist es aus Effizienzgründen sehr sinnvoll, die Fehlerprüfung durchzuführenVorDaten auf die Festplatte schreiben. Andernfalls verschwenden Sie wertvolle Ressourcen, indem Sie aus dem Archiv lesen, es auf die Festplatte schreiben und dann die Daten auf der Festplatte erneut lesen, um eine Fehlerprüfung durchzuführen. Bei einem großen Archiv oder auf einem System mit eingeschränktem Speicher kann dies die Zeit zum Dekomprimieren einer Datei verdoppeln, was inakzeptabel wäre. Ich gehe in diesem Fall davon aus, dass das Lesen und Schreiben auf der Festplatte der langsamste Teil des Prozesses ist.
Wenn Sie die Prüfung vor dem Schreiben durchführen, können Sie das Archiv effektiv durch den Dekomprimierer, durch Ihren Fehlerprüfalgorithmus und dann auf die Festplatte streamen und davon ausgehen, dass das Festplattensubsystem weiß, was es tut. Job erledigt.
Auf diese Weise wird das „Testen“ des Archivs zu einem kostenlosen Vorgang. Sie befolgen genau dieselben Schritte wie beim Dekomprimieren, aber Sie verwerfen die Daten einfach, ohne sie auf die Festplatte zu schreiben.
Ich gehe fest davon aus, dass es so funktioniert, denn alles auf die Festplatte zu schreiben, nur um ein Archiv zu testen, erscheint verrückt und wäre nicht schneller als eine „echte“ Dekomprimierung der Daten. Dass „Testen“ schneller ist, bedeutet, dass mindestens ein Schritt, höchstwahrscheinlich das Schreiben der Daten auf die Festplatte, übersprungen wird.
Antwort2
Nein, das ist nicht der Fall, zumindest nicht bei der Version 19.00.
Das parallele Testen mehrerer Dateien funktioniert auf Solid-State-Laufwerken hervorragend, beeinträchtigt jedoch normalerweise die Leistung mechanischer Laufwerke. Das parallele Lesen mehrerer Archive erfordert dann viel Sucharbeit. Daher kann folgende Empfehlung ausgesprochen werden:
Starten Sie beim Testen von Archiven auf Solid-State-Laufwerken (NVMe oder SATA SSD) so viele Prozesse, wie Sie über Kerne verfügen (falls möglich).
Starten Sie beim Testen von Archiven auf demselben mechanischen Laufwerk (oder mechanischen RAID-Volume) einen oder höchstens zwei Prozesse.
Beim Testen von Archiven auf USB-Laufwerken können die Ergebnisse unterschiedlich ausfallen.
Die traurige Mehrheit der üblichen USB-„Pen Drives“ oder „Sticks“ ist selbst beim Lesen unerträglich langsam – d. h. sie sättigen die Bandbreite der USB-Schnittstelle bei weitem nicht. Einige dieser Laufwerke werden sogar noch langsamer, wenn sie gleichzeitig auf Daten aus mehreren unterschiedlichen Bereichen des Laufwerks zugreifen. Dies wird durch den begrenzten RAM im Festplattencontroller verursacht. Der Controller kann nicht alle Metadaten, die für den Zugriff auf das gesamte Laufwerk erforderlich sind, gleichzeitig in den RAM packen und liest die Metadaten beim Wechsel der Lesebereiche auf dem Laufwerk erneut vom Flash-Medium, wobei er häufig Linkketten folgen muss, um sie zu finden. Solche Metadaten-Lesevorgänge werden vom Laufwerk häufig nicht parallelisiert, selbst wenn das Flash-Speicherlayout dies zulassen würde, und werden häufig auch mit dedizierten Codepfaden implementiert, die einfach langsam sind.
Der einzige sichere Weg, damit umzugehen, ist ein Bandbreitentest. Angenommen, Sie müssen die Archive a, b, c, d, eund verifizieren f, die alle etwa die gleiche Größenordnung von der Größe her haben. Sie müssen in absteigender Größe sortiert werden. Stoppen Sie zunächst die Zeit der Verifizierung von aund berechnen Sie die Bandbreite BW_a = time_a / size_a. Führen Sie dann die Verifizierung von bund cparallel durch und berechnen Sie diese Bandbreiten. Solange ihre Summe sum_BW_bcgrößer ist als BW_a, gewinnen Sie an Leistung. Verifizieren Sie dann d, eund fparallel und berechnen Sie diese Bandbreiten. Solange ihre Summe sum_BW_defgrößer ist als sum_BW_bc, gewinnen Sie an Leistung. Und so weiter. Irgendwann erreichen Sie die Anzahl von Streams, bei der die Gesamtbandbreite im Vergleich zum vorherigen Test sinkt. Fahren Sie dann mit der Verifizierung der verbleibenden Archive mit der vorherigen, kleineren Anzahl von Streams fort.
Diese Methode kann auf jedes Laufwerk angewendet werden, allerdings ist der Leistungsabfall bei mechanischen Laufwerken so stark, dass er die Gesamtleistung Ihres Überprüfungsprozesses übermäßig beeinträchtigen kann. Aus diesem Grund sollten die parallelen Tests beendet werden, wenn bekannt ist, dass ihre Bandbreite weniger als 90 % der Bandbreite des vorhergehenden Schritts beträgt. Sie können dies tun, indem Sie die Bandbreite jede Sekunde, in der der Test ausgeführt wird, neu berechnen und den Test beenden, wenn die Bandbreite unter dem Grenzwert liegt.