Speicherbedarf

In Abhängigkeit von den gewählten Kompressionseinstellungen bewegt sich der Speicherverbrauch zwischen wenigen hundert Kilobyte und mehreren Gigabyte. Die Einstellungen bei der Kompression einer Datei bestimmen dabei den Speicherbedarf bei der Dekompression. Die Dekompression benötigt üblicherweise zwischen 5 % und 20 % des Speichers, der bei der Kompression der Datei erforderlich war. Beispielsweise benötigt die Dekompression einer Datei, die mit xz -9 komprimiert wurde, gegenwärtig etwa 65 MiB Speicher. Es ist jedoch auch möglich, dass .xz-Dateien mehrere Gigabyte an Speicher zur Dekompression erfordern.

Insbesondere für Benutzer älterer Systeme wird eventuell ein sehr großer Speicherbedarf ärgerlich sein. Um unangenehme Überraschungen zu vermeiden, verfügt xz über eine eingebaute Begrenzung des Speicherbedarfs, die allerdings in der Voreinstellung deaktiviert ist. Zwar verfügen einige Betriebssysteme über eingebaute Möglichkeiten zur prozessabhängigen Speicherbegrenzung, doch diese sind zu unflexibel (zum Beispiel kann ulimit(1) beim Begrenzen des virtuellen Speichers mmap(2) beeinträchtigen).

Die Begrenzung des Speicherbedarfs kann mit der Befehlszeilenoption --memlimit=Begrenzung aktiviert werden. Oft ist es jedoch bequemer, die Begrenzung durch Setzen der Umgebungsvariable XZ_DEFAULTS standardmäßig zu aktivieren, zum Beispiel XZ_DEFAULTS=--memlimit=150MiB. Die Begrenzungen können getrennt für Kompression und Dekompression mittels --memlimit-compress=Begrenzung und --memlimit-decompress=Begrenzung festgelegt werden. Die Verwendung einer solchen Option außerhalb der Variable XZ_DEFAULTS ist kaum sinnvoll, da xz in einer einzelnen Aktion nicht gleichzeitig Kompression und Dekompression ausführen kann und --memlimit=Begrenzung (oder -M Begrenzung) lässt sich einfacher in der Befehlszeile eingeben.

Wenn die angegebene Speicherbegrenzung bei der Dekompression überschritten wird, schlägt der Vorgang fehl und xz zeigt eine Fehlermeldung an. Wird die Begrenzung bei der Kompression überschritten, dann versucht xz die Einstellungen entsprechend anzupassen, außer wenn --format=raw oder --no-adjust angegeben ist. Auf diese Weise schlägt die Aktion nicht fehl, es sei denn, die Begrenzung wurde sehr niedrig angesetzt. Die Anpassung der Einstellungen wird schrittweise vorgenommen, allerdings entsprechen die Schritte nicht den Voreinstellungen der Kompressionsstufen. Das bedeutet, wenn beispielsweise die Begrenzung nur geringfügig unter den Anforderungen für xz -9 liegt, werden auch die Einstellungen nur wenig angepasst und nicht vollständig herunter zu den Werten für xz -8

Verkettung und Auffüllung von .xz-Dateien

Es ist möglich, .xz-Dateien direkt zu verketten. Solche Dateien werden von xz genauso dekomprimiert wie eine einzelne .xz-Datei.

Es ist weiterhin möglich, eine Auffüllung zwischen den verketteten Teilen oder nach dem letzten Teil einzufügen. Die Auffüllung muss aus Null-Bytes bestehen und deren Größe muss ein Vielfaches von vier Byte sein. Dies kann zum Beispiel dann vorteilhaft sein, wenn die .xz-Datei auf einem Datenträger gespeichert wird, dessen Dateisystem die Dateigrößen in 512-Byte-Blöcken speichert.

Verkettung und Auffüllung sind für .lzma-Dateien oder Rohdatenströme nicht erlaubt.

Ganzzahlige Suffixe und spezielle Werte

An den meisten Stellen, wo ein ganzzahliges Argument akzeptiert wird, kann ein optionales Suffix große Ganzzahlwerte einfacher darstellen. Zwischen Ganzzahl und dem Suffix dürfen sich keine Leerzeichen befinden.

KiB

multipliziert die Ganzzahl mit 1.024 (2^10). Ki, k, kB, K und KB werden als Synonyme für KiB akzeptiert.

MiB

multipliziert die Ganzzahl mit 1.048.576 (2^20). Mi, m, M und MB werden als Synonyme für MiB akzeptiert.

GiB

multipliziert die Ganzzahl mit 1.073.741.824 (2^30). Gi, g, G und GB werden als Synonyme für GiB akzeptiert.

Der spezielle Wert max kann dazu verwendet werden, um den von der jeweiligen Option akzeptierten maximalen Ganzzahlwert anzugeben.

Aktionsmodus

Falls mehrere Aktionsmodi angegeben sind, wird der zuletzt angegebene verwendet.

-z, --compress

Kompression. Dies ist der voreingestellte Aktionsmodus, sofern keiner angegeben ist und auch kein bestimmter Modus aus dem Befehlsnamen abgeleitet werden kann (der Befehl unxz impliziert zum Beispiel --decompress).

-d, --decompress, --uncompress

dekomprimpiert.

-t, --test

prüft die Integrität der komprimierten Dateien. Diese Option ist gleichbedeutend mit --decompress --stdout, außer dass die dekomprimierten Daten verworfen werden, anstatt sie in die Standardausgabe zu leiten. Es werden keine Dateien erstellt oder entfernt.

-l, --list

gibt Informationen zu den komprimierten Dateien aus. Es werden keine unkomprimierten Dateien ausgegeben und keine Dateien angelegt oder entfernt. Im Listenmodus kann das Programm keine komprimierten Daten aus der Standardeingabe oder anderen nicht durchsuchbaren Quellen lesen.

Die Liste zeigt in der Standardeinstellung grundlegende Informationen zu den Dateien an, zeilenweise pro Datei. Detailliertere Informationen erhalten Sie mit der Option --verbose. Wenn Sie diese Option zweimal angeben, werden noch ausführlichere Informationen ausgegeben. Das kann den Vorgang allerdings deutlich verlangsamen, da die Ermittlung der zusätzlichen Informationen zahlreiche Suchvorgänge erfordert. Die Breite der ausführlichen Ausgabe übersteigt 80 Zeichen, daher könnte die Weiterleitung in beispielsweise less -S sinnvoll sein, falls das Terminal nicht breit genug ist.

Die exakte Ausgabe kann in verschiedenen xz-Versionen und Spracheinstellungen unterschiedlich sein. Wenn eine maschinell auswertbare Ausgabe gewünscht ist, dann sollten Sie --robot --list verwenden.

Aktionsattribute

-k, --keep

verhindert das Löschen der Eingabedateien.

Seit der xz-Version 5.2.6 wird die Kompression oder Dekompression auch dann ausgeführt, wenn die Eingabe ein symbolischer Link zu einer regulären Datei ist, mehr als einen harten Link hat oder das »setuid«-, »setgid«- oder »sticky«-Bit gesetzt ist. Die genannten Bits werden nicht in die Zieldatei kopiert. In früheren Versionen geschah dies nur mit --force.

-f, --force

Diese Option hat verschiedene Auswirkungen:

-c, --stdout, --to-stdout

schreibt die komprimierten oder dekomprimierten Daten in die Standardausgabe anstatt in eine Datei. Dies impliziert --keep.

--single-stream

dekomprimiert nur den ersten .xz-Datenstrom und ignoriert stillschweigend weitere Eingabedaten, die möglicherweise dem Datenstrom folgen. Normalerweise führt solcher anhängender Datenmüll dazu, dass xz eine Fehlermeldung ausgibt.

xz dekomprimiert niemals mehr als einen Datenstrom aus .lzma-Dateien oder Rohdatenströmen, aber dennoch wird durch diese Option möglicherweise vorhandener Datenmüll nach der .lzma-Datei oder dem Rohdatenstrom ignoriert.

Diese Option ist wirkungslos, wenn der Aktionsmodus nicht --decompress oder --test ist.

--no-sparse

verhindert die Erzeugung von Sparse-Dateien. In der Voreinstellung versucht xz, bei der Dekompression in eine reguläre Datei eine Sparse-Datei zu erzeugen, wenn die dekomprimierten Daten lange Abfolgen von binären Nullen enthalten. Dies funktioniert auch beim Schreiben in die Standardausgabe, sofern diese in eine reguläre Datei weitergeleitet wird und bestimmte Zusatzbedingungen erfüllt sind, die die Aktion absichern. Die Erzeugung von Sparse-Dateien kann Plattenplatz sparen und beschleunigt die Dekompression durch Verringerung der Ein-/Ausgaben der Platte.

-S .suf, --suffix=.suf

verwendet .suf bei der Dekompression anstelle von .xz oder .lzma als Suffix für die Zieldatei. Falls nicht in die Standardausgabe geschrieben wird und die Quelldatei bereits das Suffix .suf hat, wird eine Warnung angezeigt und die Datei übersprungen.

berücksichtigt bei der Dekompression zusätzlich zu Dateien mit den Suffixen .xz, .txz, .lzma, .tlz oder .lz auch jene mit dem Suffix .suf. Falls die Quelldatei das Suffix .suf hat, wird dieses entfernt und so der Name der Zieldatei abgeleitet.

Beim Komprimieren oder Dekomprimieren von Rohdatenströmen mit --format=raw muss das Suffix stets angegeben werden, außer wenn die Ausgabe in die Standardausgabe erfolgt. Der Grund dafür ist, dass es kein vorgegebenes Suffix für Rohdatenströme gibt.

--files[=Datei]

liest die zu verarbeitenden Dateinamen aus Datei. Falls keine Datei angegeben ist, werden die Dateinamen aus der Standardeingabe gelesen. Dateinamen müssen mit einem Zeilenumbruch beendet werden. Ein Bindestrich (-) wird als regulärer Dateiname angesehen und nicht als Standardeingabe interpretiert. Falls Dateinamen außerdem als Befehlszeilenargumente angegeben sind, werden diese vor den Dateinamen aus der Datei verarbeitet.

--files0[=Datei]

Dies ist gleichbedeutend mit --files[=Datei], außer dass jeder Dateiname mit einem Null-Zeichen abgeschlossen werden muss.

Grundlegende Dateiformat- und Kompressionsoptionen

-F Format, --format=Format

gibt das Format der zu komprimierenden oder dekomprimierenden Datei an:

-C Prüfung, --check=Prüfung

gibt den Typ der Integritätsprüfung an. Die Prüfsumme wird aus den unkomprimierten Daten berechnet und in der .xz-Datei gespeichert. Diese Option wird nur bei der Kompression in das .xz-Format angewendet, da das .lzma-Format keine Integritätsprüfungen unterstützt. Die eigentliche Integritätsprüfung erfolgt (falls möglich), wenn die .xz-Datei dekomprimiert wird.

Folgende Typen von Prüfungen werden unterstützt:

Die Integrität der .xz-Header wird immer mit CRC32 geprüft. Es ist nicht möglich, dies zu ändern oder zu deaktivieren.

--ignore-check

verifiziert die Integritätsprüfsumme der komprimierten Daten bei der Dekompression nicht. Die CRC32-Werte in den .xz-Headern werden weiterhin normal verifiziert.

Verwenden Sie diese Option nicht, außer Sie wissen, was Sie tun. Mögliche Gründe, diese Option zu verwenden:

-0 … -9

wählt eine der voreingestellten Kompressionsstufen, standardmäßig -6. Wenn mehrere Voreinstellungsstufen angegeben sind, ist nur die zuletzt angegebene wirksam. Falls bereits eine benutzerdefinierte Filterkette angegeben wurde, wird diese durch die Festlegung der Voreinstellung geleert.

Die Unterschiede zwischen den Voreinstellungsstufen sind deutlicher als bei gzip(1) und bzip2(1). Die gewählten Kompressionseinstellungen bestimmen den Speicherbedarf bei der Dekompression, daher ist es auf älteren Systemen mit wenig Speicher bei einer zu hoch gewählten Voreinstellung schwer, eine Datei zu dekomprimieren. Insbesondere ist es keine gute Idee, blindlings -9 für alles zu verwenden, wie dies häufig mit gzip(1) und bzip2(1) gehandhabt wird.

Auf der gleichen Hardware ist die Dekompressionsgeschwindigkeit ein nahezu konstanter Wert in Bytes komprimierter Daten pro Sekunde. Anders ausgedrückt: Je besser die Kompression, umso schneller wird üblicherweise die Dekompression sein. Das bedeutet auch, dass die Menge der pro Sekunde ausgegebenen unkomprimierten Daten stark variieren kann.

Die folgende Tabelle fasst die Eigenschaften der Voreinstellungen zusammen:

Spaltenbeschreibungen:

Der Speicherbedarf einiger der zukünftigen Multithread-Modi kann dramatisch höher sein als im Einzel-Thread-Modus. Mit dem Standardwert von --block-size benötigt jeder Thread 3*3*Wörtb.Gr plus KompSpeich oder DekompSpeich. Beispielsweise benötigen vier Threads mit der Voreinstellung -6 etwa 660 bis 670 MiB Speicher.

-e, --extreme

verwendet eine langsamere Variante der gewählten Kompressions-Voreinstellungsstufe (-0 … -9), um hoffentlich ein etwas besseres Kompressionsverhältnis zu erreichen, das aber in ungünstigen Fällen auch schlechter werden kann. Der Speicherverbrauch bei der Dekompression wird dabei nicht beeinflusst, aber der Speicherverbrauch der Kompression steigt in den Voreinstellungsstufen -0 bis -3 geringfügig an.

Da es zwei Voreinstellungen mit den Wörterbuchgrößen 4 MiB und 8 MiB gibt, verwenden die Voreinstellungsstufen -3e und -5e etwas schnellere Einstellungen (niedrigere KompCPU) als -4e beziehungsweise -6e. Auf diese Weise sind zwei Voreinstellungen nie identisch.

Zum Beispiel gibt es insgesamt vier Voreinstellungen, die ein 8 MiB großes Wörterbuch verwenden, deren Reihenfolge von der schnellsten zur langsamsten -5, -6, -5e und -6e ist.

--fast

--best

sind etwas irreführende Aliase für -0 beziehungsweise -9. Sie werden nur zwecks Abwärtskompatibilität zu den LZMA-Dienstprogrammen bereitgestellt. Sie sollten diese Optionen besser nicht verwenden.

--block-size=Größe

teilt beim Komprimieren in das .xz-Format die Eingabedaten in Blöcke der angegebenen Größe in Byte. Die Blöcke werden unabhängig voneinander komprimiert, was dem Multi-Threading entgegen kommt und Zufallszugriffe bei der Dekompression begrenzt. Diese Option wird typischerweise eingesetzt, um die vorgegebene Blockgröße im Multi-Thread-Modus außer Kraft zu setzen, aber sie kann auch im Einzel-Thread-Modus angewendet werden.

Im Multi-Thread-Modus wird etwa die dreifache Größe in jedem Thread zur Pufferung der Ein- und Ausgabe belegt. Die vorgegebene Größe ist das Dreifache der Größe des LZMA2-Wörterbuchs oder 1 MiB, je nachdem, was mehr ist. Typischerweise ist das Zwei- bis Vierfache der Größe des LZMA2-Wörterbuchs oder wenigstens 1 MB ein guter Wert. Eine Größe, die geringer ist als die des LZMA2-Wörterbuchs, ist Speicherverschwendung, weil dann der LZMA2-Wörterbuchpuffer niemals vollständig genutzt werden würde. Im Multi-Thread-Modus wird die Größe der Blöcke wird in den Block-Headern gespeichert. Die Größeninformation wird für eine Multi-Thread-Dekompression genutzt.

Im Einzel-Thread-Modus werden die Blöcke standardmäßig nicht geteilt. Das Setzen dieser Option wirkt sich nicht auf den Speicherbedarf aus. In den Block-Headern werden keine Größeninformationen gespeichert, daher werden im Einzel-Thread-Modus erzeugte Dateien nicht zu den im Multi-Thread-Modus erzeugten Dateien identisch sein. Das Fehlen der Größeninformation bedingt auch, dass xz nicht in der Lage sein wird, die Dateien im Multi-Thread-Modus zu dekomprimieren.

--block-list=Blöcke

beginnt bei der Kompression in das .xz-Format nach den angegebenen Intervallen unkomprimierter Daten einen neuen Block, optional mit einer benutzerdefinierten Filterkette.

Die Blöcke werden in einer durch Kommata getrennten Liste angegeben. Jeder Block besteht aus einer optionalen Filterkettennummer zwischen 0 und 9, gefolgt von einem Doppelpunkt (:) und der Größe der unkomprimierten Daten (diese Angabe ist erforderlich). Überspringen eines Blocks (zwei oder mehr aufeinander folgende Kommata) ist ein Kürzel dafür, die Größe und die Filter des vorherigen Blocks zu verwenden.

Falls die Eingabedatei größer ist als die Summe der Blöcke, dann wird der letzte in VBlöcke angegebene Wert bis zum Ende der Datei wiederholt. Mit dem speziellen Wert 0 können Sie angeben, dass der Rest der Datei als einzelner Block kodiert werden soll.

Eine alternative Filterkette für jeden Block kann in Kombination mit den Optionen --filters1=Filter … --filters9=Filter angegeben werden. Diese Optionen definieren Filterketten mit einem Bezeichner zwischen 1 und 9. Die Filterkette 0 bezeichnet hierbei die voreingestellte Filterkette, was dem Nichtangeben einer Filterkette gleichkommt. Der Filterkettenbezeichner kann vor der unkomprimierten Größe verwendet werden, gefolgt von einem Doppelpunkt (:). Falls Sie beispielsweise --block-list=1:2MiB,3:2MiB,2:4MiB,,2MiB,0:4MiB angeben, werden die Blöcke folgendermaßen erstellt:

Falls Sie eine Größe angeben, welche die Blockgröße des Encoders übersteigen (entweder den Vorgabewert im Thread-Modus oder den mit --block-size=Größe angegebenen Wert), wird der Encoder zusätzliche Blöcke erzeugen, wobei die in den Blöcke angegebenen Grenzen eingehalten werden. Wenn Sie zum Beispiel --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB angeben und die Eingabedatei 80 MiB groß ist, erhalten Sie 11 Blöcke: 5, 10, 8, 10, 2, 10, 10, 4, 10, 10 und 1 MiB.

Im Multi-Thread-Modus werden die Blockgrößen in den Block-Headern gespeichert. Dies geschieht im Einzel-Thread-Modus nicht, daher wird die kodierte Ausgabe zu der im Multi-Thread-Modus nicht identisch sein.

--flush-timeout=Zeit

löscht bei der Kompression die ausstehenden Daten aus dem Encoder und macht sie im Ausgabedatenstrom verfügbar, wenn mehr als die angegebene Zeit in Millisekunden (als positive Ganzzahl) seit dem vorherigen Löschen vergangen ist und das Lesen weiterer Eingaben blockieren würde. Dies kann nützlich sein, wenn xz zum Komprimieren von über das Netzwerk eingehenden Daten verwendet wird. Kleine Zeit-Werte machen die Daten unmittelbar nach dem Empfang nach einer kurzen Verzögerung verfügbar, während große Zeit-Werte ein besseres Kompressionsverhältnis bewirken.

Dieses Funktionsmerkmal ist standardmäßig deaktiviert. Wenn diese Option mehrfach angegeben wird, ist die zuletzt angegebene wirksam. Für die Angabe der Zeit kann der spezielle Wert 0 verwendet werden, um dieses Funktionsmerkmal explizit zu deaktivieren.

Dieses Funktionsmerkmal ist außerhalb von POSIX-Systemen nicht verfügbar.

Dieses Funktionsmerkmal ist noch experimentell. Gegenwärtig ist xz aufgrund der Art und Weise, wie xz puffert, für Dekompression in Echtzeit ungeeignet.

--memlimit-compress=Grenze

legt eine Grenze für die Speichernutzung bei der Kompression fest. Wenn diese Option mehrmals angegeben wird, ist die zuletzt angegebene wirksam.

Falls die Kompressionseinstellungen die Grenze überschreiten, versucht xz, die Einstellungen nach unten anzupassen, so dass die Grenze nicht mehr überschritten wird und zeigt einen Hinweis an, dass eine automatische Anpassung vorgenommen wurde. Die Anpassungen werden in folgender Reihenfolge angewendet: Reduzierung der Anzahl der Threads, Wechsel in den Einzelthread-Modus, falls sogar ein einziger Thread im Multithread-Modus die Grenze überschreitet, und schlussendlich die Reduzierung der Größe des LZMA2-Wörterbuchs.

Beim Komprimieren mit --format=raw oder falls --no-adjust angegeben wurde, wird nur die Anzahl der Threads reduziert, da nur so die komprimierte Ausgabe nicht beeinflusst wird.

Falls die Grenze nicht anhand der vorstehend beschriebenen Anpassungen gesetzt werden kann, wird ein Fehler angezeigt und xz wird mit dem Exit-Status 1 beendet.

Die Grenze kann auf verschiedene Arten angegeben werden:

Für die 32-Bit-Version von xz gibt es einen Spezialfall: Falls die Grenze über 4020 MiB liegt, wird die Grenze auf 4020 MiB gesetzt. Auf MIPS32 wird stattdessen 2000 MB verwendet (die Werte 0 und max werden hiervon nicht beeinflusst; für die Dekompression gibt es keine vergleichbare Funktion). Dies kann hilfreich sein, wenn ein 32-Bit-Executable auf einen 4 GiB großen Adressraum (2 GiB auf MIPS32) zugreifen kann, wobei wir hoffen wollen, dass es in anderen Situationen keine negativen Effekte hat.

Siehe auch den Abschnitt Speicherbedarf.

--memlimit-decompress=Grenze

legt eine Begrenzung des Speicherverbrauchs für die Dekompression fest. Dies beeinflusst auch den Modus --list. Falls die Aktion nicht ausführbar ist, ohne die Grenze zu überschreiten, gibt xz eine Fehlermeldung aus und die Dekompression wird fehlschlagen. Siehe --memlimit-compress=Grenze zu möglichen Wegen, die Grenze anzugeben.

--memlimit-mt-decompress=Grenze

legt eine Begrenzung des Speicherverbrauchs für Multithread-Dekompression fest. Dies beeinflusst lediglich die Anzahl der Threads; xz wird dadurch niemals die Dekompression einer Datei verweigern. Falls die Grenze für jegliches Multithreading zu niedrig ist, wird sie ignoriert und xz setzt im Einzelthread-modus fort. Beachten Sie auch, dass bei der Verwendung von --memlimit-decompress dies stets sowohl auf den Einzelthread-als auch auf den Multithread-Modus angewendet wird und so die effektive Grenze für den Multithread-Modus niemals höher sein wird als die mit --memlimit-decompress gesetzte Grenze.

Im Gegensatz zu anderen Optionen zur Begrenzung des Speicherverbrauchs hat --memlimit-mt-decompress=Grenze eine systemspezifisch vorgegebene Grenze. Mit xz --info-memory können Sie deren aktuellen Wert anzeigen lassen.

Diese Option und ihr Standardwert existieren, weil die unbegrenzte threadbezogene Dekompression bei einigen Eingabedateien zu unglaublich großem Speicherverbrauch führen würde. Falls die vorgegebene Grenze auf Ihrem System zu niedrig ist, können Sie die Grenze durchaus erhöhen, aber setzen Sie sie niemals auf einen Wert größer als die Menge des nutzbaren Speichers, da xz bei entsprechenden Eingabedateien versuchen wird, diese Menge an Speicher auch bei einer geringen Anzahl von Threads zu verwnden. Speichermangel oder Auslagerung verbessern die Dekomprimierungsleistung nicht.

Siehe --memlimit-compress=Grenze für mögliche Wege zur Angabe der Grenze. Sezen der Grenze auf 0 setzt die Grenze auf den vorgegebenen systemspezifischen Wert zurück.

-M Grenze, --memlimit=Grenze, --memory=Grenze

Dies ist gleichbedeutend mit --memlimit-compress=Grenze --memlimit-decompress=Grenze --memlimit-mt-decompress=Grenze.

--no-adjust

zeigt einen Fehler an und beendet, falls die Grenze der Speichernutzung nicht ohne Änderung der Einstellungen, welche die komprimierte Ausgabe beeinflussen, berücksichtigt werden kann. Das bedeutet, dass xz daran gehindert wird, den Encoder vom Multithread-Modus in den Einzelthread-Modus zu versetzen und die Größe des LZMA2-Wörterbuchs zu reduzieren. Allerdings kann bei Verwendung dieser Option dennoch die Anzahl der Threads reduziert werden, um die Grenze der Speichernutzung zu halten, sofern dies die komprimierte Ausgabe nicht beeinflusst.

Die automatische Anpassung ist beim Erzeugen von Rohdatenströmen (--format=raw) immer deaktiviert.

-T Threads, --threads=Threads

gibt die Anzahl der zu verwendenden Arbeits-Threads an. Wenn Sie Threads auf einen speziellen Wert 0 setzen, verwendet xz maximal so viele Threads, wie der/die Prozessor(en) im System untestützen. Die tatsächliche Anzahl kann geringer sein als die angegebenen Threads, wenn die Eingabedatei nicht groß genug für Threading mit den gegebenen Einstellungen ist oder wenn mehr Threads die Speicherbegrenzung übersteigen würden.

Die Multithread- bzw. Einzelthread-Kompressoren erzeugen unterschiedliche Ausgaben. Der Einzelthread-Kompressor erzeugt die geringste Dateigröße, aber nur die Ausgabe des Multithread-Kompressors kann mit mehreren Threads wieder dekomprimiert werden. Das Setzen der Anzahl der Threads auf 1 wird den Einzelthread-Modus verwenden. Das Setzen der Anzahl der Threads auf einen anderen Wert einschließlich 0 verwendet den Multithread-Kompressor, und zwar sogar dann, wenn das System nur einen einzigen Hardware-Thread unterstützt (xz 5.2.x verwendete in diesem Fall noch den Einzelthread-Modus).

Um den Multithread-Modus mit nur einem einzigen Thread zu verwenden, setzen Sie die Anzahl der Threads auf +1. Das Präfix + hat mit Werten verschieden von 1 keinen Effekt. Eine Begrenzung des Speicherverbrauchs kann xz dennoch veranlassen, den Einzelthread-Modus zu verwenden, außer wenn --no-adjust verwendet wird. Die Unterstützung für das Präfix + wurde in xz 5.4.0 hinzugefügt.

Falls das automatische Setzen der Anzahl der Threads angefordert und keine Speicherbegrenzung angegeben wurde, dann wird eine systemspezifisch vorgegebene weiche Grenze verwendet, um eventuell die Anzahl der Threads zu begrenzen. Es ist eine weiche Grenze im Sinne davon, dass sie ignoriert wird, falls die Anzahl der Threads 1 ist; daher wird eine weiche Grenze xz niemals an der Kompression oder Dekompression hindern. Diese vorgegebene weiche Grenze veranlasst xz nicht, vom Multithread-Modus in den Einzelthread-Modus zu wechseln. Die aktiven Grenzen können Sie mit dem Befehl xz --info-memory anzeigen lassen.

Die gegenwärtig einzige Threading-Methode teilt die Eingabe in Blöcke und komprimiert diese unabhängig voneinander. Die vorgegebene Blockgröße ist von der Kompressionsstufe abhängig und kann mit der Option --block-size=Größe außer Kraft gesetzt werden.

Eine thread-basierte Dekompression wird nur bei Dateien funktionieren, die mehrere Blöcke mit Größeninformationen in deren Headern enthalten. Alle im Multi-Thread-Modus komprimierten Dateien, die groß genug sind, erfüllen diese Bedingung, im Einzel-Thread-Modus komprimierte Dateien dagegen nicht, selbst wenn --block-size=Größe verwendet wurde.

Der Vorgabewert für Threads is 0. In xz 5.4.x und älteren Versionen ist der Vorgabewert 1.

Benutzerdefinierte Filterketten für die Kompression

Eine benutzerdefinierte Filterkette ermöglicht die Angabe detaillierter Kompressionseinstellungen, anstatt von den Voreinstellungen auszugehen. Wenn eine benutzerdefinierte Filterkette angegeben wird, werden die vorher in der Befehlszeile angegebenen Voreinstellungsoptionen (-0 … -9 und --extreme) außer Kraft gesetzt. Wenn eine Voreinstellungsoption nach einer oder mehreren benutzerdefinierten Filterkettenoptionen angegeben wird, dann wird die neue Voreinstellung wirksam und die zuvor angegebenen Filterkettenoptionen werden außer Kraft gesetzt.

Eine Filterkette ist mit dem Piping (der Weiterleitung) in der Befehlszeile vergleichbar. Bei der Kompression gelangt die unkomprimierte Eingabe in den ersten Filter, dessen Ausgabe wiederum in den zweiten Filter geleitet wird (sofern ein solcher vorhanden ist). Die Ausgabe des letzten Filters wird in die komprimierte Datei geschrieben. In einer Filterkette sind maximal vier Filter zulässig, aber typischerweise besteht eine Filterkette nur aus einem oder zwei Filtern.

Bei vielen Filtern ist die Positionierung in der Filterkette eingeschränkt: Einige Filter sind nur als letzte in der Kette verwendbar, einige können nicht als letzte Filter gesetzt werden, und andere funktionieren an beliebiger Stelle. Abhängig von dem Filter ist diese Beschränkung entweder auf das Design des Filters selbst zurückzuführen oder ist aus Sicherheitsgründen vorhanden.

Eine benutzerdefinierte Filterkette kann auf zwei verschiedene Arten angegeben werden. Die Optionen --filters=Filter und --filters1=Filter … --filters9=Filter ermöglichen die Angabe einer ganzen Filterkette in einer einzelnen Option gemäß der Liblzma-Filterzeichenkettensyntax. Alternativ können Sie eine Filterkette mit einer oder mehreren individuellen Filteroptionen in der Reihenfolge angeben, in der sie in der Filterkette verwendet werden sollen. Daher ist die Reihenfolge der individuellen Filteroptionen wichtig! Beim Dekodieren von Rohdatenströmen (--format=raw) muss die Filterkette in der gleichen Reihenfolge wie bei der Komprimierung angegeben werden. Alle individuellen Filter- oder Voreinstellungsoptionen, die vor der vollen Filterkettenoption (--filters=Filter) angegeben werden, werden verworfen. Individuelle Filter, die nach der vollen Filterkettenoption angegeben werden, setzen die Filterkette zurück

Sowohl vollständige als auch individuelle Filteroptionen akzeptieren filterspezifische Optionen in einer durch Kommata getrennten Liste. Zusätzliche Kommata in den Optionen werden ignoriert. Jede Option hat einen Standardwert, daher brauchen Sie nur jene anzugeben, die Sie ändern wollen.

Um die gesamte Filterkette und die Optionen anzuzeigen, rufen Sie xz -vv auf (was gleichbedeutend mit der zweimaligen Angabe von --verbose ist). Dies funktioniert auch zum Betrachten der von den Voreinstellungen verwendeten Filterkettenoptionen.

--filters=Filter

gibt die vollständige Filterkette oder eine Voreinstellung in einer einzelnen Option an. Mehrere Filter können durch Leerzeichen oder zwei Minuszeichen (--) voneinander getrennt werden. Es kann notwendig sein, die Filter in der Shell-Befehlszeile zu maskieren, so dass diese als einzelne Option ausgewertet werden. Um Optionen Werte zuzuordnen, verwenden Sie : oder =. Einer Voreinstellung kann ein - vorangestellt werden, dem keiner oder mehrere Schalter folgen. Der einzige unterstützte Schalter ist e zum Anwenden der gleichen Optionen wie --extreme.

--filters1=Filter … --filters9=Filter

gibt bis zu neun optionale Filterketten an, die mit --block-list verwendet werden können.

Wenn Sie beispielsweise ein Archiv mit ausführbaren Dateien gefolgt von Textdateien komprimieren, könnte der Teil mit den ausführbaren Dateien eine Filterkette mit einem BCJ-Filter und der Textdateiteil lediglich den LZMA2-Filter verwenden.

--filters-help

zeigt eine Hilfemeldung an, welche beschreibt, wie Voreinstellungen und benutzerdefinierte Filterketten in den Optionen --filters und --filters1=Filter … --filters9=Filter angegeben werden und beendet das Programm.

--lzma1[=Optionen]

--lzma2[=Optionen]

fügt LZMA1- oder LZMA2-Filter zur Filterkette hinzu. Diese Filter können nur als letzte Filter in der Kette verwendet werden.

LZMA1 ist ein veralteter Filter, welcher nur wegen des veralteten .lzma-Dateiformats unterstützt wird, welches nur LZMA1 unterstützt. LZMA2 ist eine aktualisierte Version von LZMA1, welche einige praktische Probleme von LZMA1 behebt. Das .xz-Format verwendet LZMA2 und unterstützt LZMA1 gar nicht. Kompressionsgeschwindigkeit und -verhältnis sind bei LZMA1 und LZMA2 praktisch gleich.

LZMA1 und LZMA2 haben die gleichen Optionen:

Beim Dekodieren von Rohdatenströmen (--format=raw) benötigt LZMA2 nur die Wörterbuch-Größe. LZMA1 benötigt außerdem lc, lp und pb.

--x86[=Optionen]

--arm[=Optionen]

--armthumb[=Optionen]

--arm64[=Optionen]

--powerpc[=Optionen]

--ia64[=Optionen]

--sparc[=Optionen]

--riscv[=Optionen]

fügt ein »Branch/Call/Jump«-(BCJ-)Filter zur Filterkette hinzu. Diese Filter können nicht als letzter Filter in der Filterkette verwendet werden.

Ein BCJ-Filter wandelt relative Adressen im Maschinencode in deren absolute Gegenstücke um. Die Datengröße wird dadurch nicht geändert, aber die Redundanz erhöht, was LZMA2 dabei helfen kann, eine um 10 bis 15% kleinere .xz-Datei zu erstellen. Die BCJ-Filter sind immer reversibel, daher verursacht die Anwendung eines BCJ-Filters auf den falschen Datentyp keinen Datenverlust, wobei aber das Kompressionsverhältnis etwas schlechter werden könnte. Die BCJ-Filter sind sehr schnell und verbrauchen nur wenig mehr Speicher.

Diese BCJ-Filter haben bekannte Probleme mit dem Kompressionsverhältnis:

Verschiedene Befehlssätze haben unterschiedliche Ausrichtungen: Die ausführbare Datei muss in den Eingabedateien einem Vielfachen dieses Wertes entsprechen, damit dieser Filter funktioniert.

Da die BCJ-gefilterten Daten üblicherweise mit LZMA2 komprimiert sind, kann das Kompressionsverhältnis dadurch etwas verbessert werden, dass die LZMA2-Optionen so gesetzt werden, dass sie der Ausrichtung des gewählten BCJ-Filters entsprechen. Beispiele:

Alle BCJ-Filter unterstützen die gleichen Optionen:

--delta[=Optionen]

fügt den Delta-Filter zur Filterkette hinzu. Der Delta-Filter kann nicht als letzter Filter in der Filterkette verwendet werden.

Gegenwärtig wird nur eine einfache, Byte-bezogene Delta-Berechnung unterstützt. Beim Komprimieren von zum Beispiel unkomprimierten Bitmap-Bildern oder unkomprimierten PCM-Audiodaten kann es jedoch sinnvoll sein. Dennoch können für spezielle Zwecke entworfene Algorithmen deutlich bessere Ergebnisse als Delta und LZMA2 liefern. Dies trifft insbesondere auf Audiodaten zu, die sich zum Beispiel mit flac(1) schneller und besser komprimieren lassen.

Unterstützte Optionen:

Andere Optionen

-q, --quiet

unterdrückt Warnungen und Hinweise. Geben Sie dies zweimal an, um auch Fehlermeldungen zu unterdrücken. Diese Option wirkt sich nicht auf den Exit-Status aus. Das bedeutet, das selbst bei einer unterdrückten Warnung der Exit-Status zur Anzeige einer Warnung dennoch verwendet wird.

-v, --verbose

bewirkt ausführliche Ausgaben. Wenn die Standardfehlerausgabe mit einem Terminal verbunden ist, zeigt xz den Fortschritt an. Durch zweimalige Angabe von --verbose wird die Ausgabe noch ausführlicher.

Der Fortschrittsanzeiger stellt die folgenden Informationen dar:

Wenn die Standardfehlerausgabe kein Terminal ist, schreibt xz mit --verbose nach dem Komprimieren oder Dekomprimieren der Datei in einer einzelnen Zeile den Dateinamen, die komprimierte Größe, die unkomprimierte Größe, das Kompressionsverhältnis und eventuell auch die Geschwindigkeit und die vergangene Zeit in die Standardfehlerausgabe. Die Geschwindigkeit und die vergangene Zeit werden nur angezeigt, wenn der Vorgang mindestens ein paar Sekunden gedauert hat. Wurde der Vorgang nicht beendet, zum Beispiel weil ihn der Benutzer abgebrochen hat, wird außerdem der Prozentsatz des erreichten Verarbeitungsfortschritts aufgenommen, sofern die Größe der Eingabedatei bekannt ist.

-Q, --no-warn

setzt den Exit-Status nicht auf 2, selbst wenn eine Bedingung erfüllt ist, die eine Warnung gerechtfertigt hätte. Diese Option wirkt sich nicht auf die Ausführlichkeitsstufe aus, daher müssen sowohl --quiet als auch --no-warn angegeben werden, um einerseits keine Warnungen anzuzeigen und andererseits auch den Exit-Status nicht zu ändern.

--robot

gibt Meldungen in einem maschinenlesbaren Format aus. Dadurch soll das Schreiben von Frontends erleichtert werden, die xz anstelle von Liblzma verwenden wollen, was in verschiedenen Skripten der Fall sein kann. Die Ausgabe mit dieser aktivierten Option sollte über mehrere xz-Veröffentlichungen stabil sein. Details hierzu finden Sie im Abschnitt ROBOTER-MODUS.

--info-memory

zeigt in einem menschenlesbaren Format an, wieviel physischen Speicher (RAM) und wie viele Prozessor-Threads das System nach Annahme von xz hat, sowie die Speicherbedarfsbegrenzung für Kompression und Dekompression, und beendet das Programm erfolgreich.

-h, --help

zeigt eine Hilfemeldung mit den am häufigsten genutzten Optionen an und beendet das Programm erfolgreich.

-H, --long-help

zeigt eine Hilfemeldung an, die alle Funktionsmerkmale von xz beschreibt und beendet das Programm erfolgreich.

-V, --version

zeigt die Versionsnummer von xz und Liblzma in einem menschenlesbaren Format an. Um eine maschinell auswertbare Ausgabe zu erhalten, geben Sie --robot vor --version an.

Listenmodus

xz --robot --list verwendet eine durch Tabulatoren getrennte Ausgabe. In der ersten Spalte jeder Zeile bezeichnet eine Zeichenkette den Typ der Information, die in dieser Zeile enthalten ist:

name

Dies ist stets die erste Zeile, wenn eine Datei aufgelistet wird. Die zweite Spalte in der Zeile enthält den Dateinamen.

file

Diese Zeile enthält allgemeine Informationen zur .xz-Datei. Diese Zeile wird stets nach der name-Zeile ausgegeben.

stream

Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt genau so viele stream-Zeilen, wie Datenströme in der .xz-Datei enthalten sind.

block

Dieser Zeilentyp wird nur verwendet, wenn --verbose angegeben wurde. Es gibt so viele block-Zeilen, wie Blöcke in der .xz-Datei. Die block-Zeilen werden nach allen stream-Zeilen angezeigt; verschiedene Zeilentypen werden nicht verschachtelt.

summary

Dieser Zeilentyp wird nur verwendet, wenn --verbose zwei Mal angegeben wurde. Diese Zeile wird nach allen block-Zeilen ausgegeben. Wie die file-Zeile enthält die summary-Zeile allgemeine Informationen zur .xz-Datei.

totals

Diese Zeile ist immer die letzte der Listenausgabe. Sie zeigt die Gesamtanzahlen und -größen an.

Die Spalten der file-Zeilen:

Die Spalten der stream-Zeilen:

Die Spalten der block-Zeilen:

Wenn --verbose zwei Mal angegeben wurde, werden zusätzliche Spalten in die block-Zeilen eingefügt. Diese werden mit einem einfachen --verbose nicht angezeigt, da das Ermitteln dieser Informationen viele Suchvorgänge erfordert und daher recht langsam sein kann:

Die Spalten der summary-Zeilen:

Die Spalten der totals-Zeile:

Wenn --verbose zwei Mal angegeben wird, werden zusätzliche Spalten in die totals-Zeile eingefügt:

Zukünftige Versionen könnten neue Zeilentypen hinzufügen, weiterhin könnten auch in den vorhandenen Zeilentypen weitere Spalten hinzugefügt werden, aber die existierenden Spalten werden nicht geändert.

Filterhilfe

xz --robot --filters-help gibt die unterstützten Filter im folgenden Format aus:

Filter:Option=<Wert>,Option=<Wert> …

Filter

Name des Filters

Option

Name der filterspezifischen Option

Wert

Der numerische Wert erscheint als Bereich <Minimum-Maximum>. Die Auswahl des Zeichenketten-Werts wird in < > eingeschlossen und durch | getrennt.

Jeder Filter wird in einer separaten Zeile ausgegeben.

Informationen zur Speicherbedarfsbegrenzung

xz --robot --info-memory gibt eine einzelne Zeile mit mehreren durch Tabulatoren getrennten Spalten aus:

1.

Gesamter physischer Speicher (RAM) in Byte.

2.

Speicherbedarfsbegrenzung für die Kompression in Byte (--memlimit-compress). Ein spezieller Wert von 0 bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist.

3.

Speicherbedarfsbegrenzung für die Dekompression in Byte (--memlimit-decompress). Ein spezieller Wert von 0 bezeichnet die Standardeinstellung, die im Einzelthread-Modus bedeutet, dass keine Begrenzung vorhanden ist.

4.

Seit xz 5.3.4alpha: Die Speichernutzung für Multithread-Dekompression in Byte (--memlimit-mt-decompress). Dies ist niemals 0, da ein systemspezifischer Vorgabewert (gezeigt in Spalte 5) verwendet wird, falls keine Grenze ausdrücklich angegeben wurde. Dies ist außerdem niemals größer als der Wert in in Spalte 3, selbst wenn mit --memlimit-mt-decompress ein größerer Wert angegeben wurde.

5.

Seit xz 5.3.4alpha: Eine systemspezifisch vorgegebene Begrenzung des Speicherverbrauchs, die zur Begrenzung der Anzahl der Threads beim Komprimieren mit automatischer Anzahl der Threads (--threads=0) und wenn keine Speicherbedarfsbegrenzung angegeben wurde (--memlimit-compress) verwendet wird. Dies wird auch als Standardwert für --memlimit-mt-decompress verwendet.

6.

Seit xz 5.3.4alpha: Anzahl der verfügbaren Prozessorthreads.

In der Zukunft könnte die Ausgabe von xz --robot --info-memory weitere Spalten enthalten, aber niemals mehr als eine einzelne Zeile.

Version

xz --robot --version gibt die Versionsnummern von xz und Liblzma im folgenden Format aus:

XZ_VERSION=XYYYZZZS
LIBLZMA_VERSION=XYYYZZZS

X

Hauptversion.

YYY

Unterversion. Gerade Zahlen bezeichnen eine stabile Version. Ungerade Zahlen bezeichnen Alpha- oder Betaversionen.

ZZZ

Patch-Stufe für stabile Veröffentlichungen oder einfach nur ein Zähler für Entwicklungsversionen.

S

Stabilität. 0 ist Alpha, 1 ist Beta und 2 ist stabil. S sollte immer 2 sein, wenn YYY eine gerade Zahl ist.

XYYYZZZS sind in beiden Zeilen gleich, sofern xz und Liblzma aus der gleichen Veröffentlichung der XZ-Utils stammen.

Beispiele: 4.999.9beta ist 49990091 und 5.0.0 is 50000002.

Voreinstellungsstufen zur Kompression

Die Nummerierung der Voreinstellungsstufen der Kompression ist in xz und den LZMA-Utils unterschiedlich. Der wichtigste Unterschied ist die Zuweisung der Wörterbuchgrößen zu den verschiedenen Voreinstellungsstufen. Die Wörterbuchgröße ist etwa gleich dem Speicherbedarf bei der Dekompression.

Die Unterschiede in der Wörterbuchgröße beeinflussen auch den Speicherbedarf bei der Kompression, aber es gibt noch einige andere Unterschiede zwischen den LZMA-Utils und den XZ-Utils, die die Kluft noch vergrößern:

Die standardmäßige Voreinstellungsstufe in den LZMA-Utils ist -7, während diese in den XZ-Utils -6 ist, daher verwenden beide standardmäßig ein 8 MiB großes Wörterbuch.

Vor- und Nachteile von .lzma-Dateien als Datenströme

Die unkomprimierte Größe der Datei kann in den .lzma-Headern gespeichert werden. Die LZMA-Utils tun das beim Komprimieren gewöhnlicher Dateien. Als Alternative kann die unkomprimierte Größe als unbekannt markiert und eine Nutzdatenende-Markierung (end-of-payload) verwendet werden, um anzugeben, wo der Dekompressor stoppen soll. Die LZMA-Utils verwenden diese Methode, wenn die unkomprimierte Größe unbekannt ist, was beispielsweise in Pipes (Befehlsverkettungen) der Fall ist.

xz unterstützt die Dekompression von .lzma-Dateien mit oder ohne Nutzdatenende-Markierung, aber alle von xz erstellten .lzma-Dateien verwenden diesen Nutzdatenende-Markierung, wobei die unkomprimierte Größe in den .lzma-Headern als unbekannt markiert wird. Das könnte in einigen unüblichen Situationen ein Problem sein. Zum Beispiel könnte ein .lzma-Dekompressor in einem Gerät mit eingebettetem System nur mit Dateien funktionieren, deren unkomprimierte Größe bekannt ist. Falls Sie auf dieses Problem stoßen, müssen Sie die LZMA-Utils oder das LZMA-SDK verwenden, um .lzma-Dateien mit bekannter unkomprimierter Größe zu erzeugen.

Nicht unterstützte .lzma-Dateien

Das .lzma-Format erlaubt lc-Werte bis zu 8 und lp-Werte bis zu 4. Die LZMA-Utils können Dateien mit beliebigem lc und lp dekomprimieren, aber erzeugen immer Dateien mit lc=3 und lp=0. Das Erzeugen von Dateien mit anderem lc und lp ist mit xz und mit dem LZMA-SDK möglich.

Die Implementation des LZMA-Filters in liblzma setzt voraus, dass die Summe von lc und lp nicht größer als 4 ist. Daher können .lzma-Dateien, welche diese Begrenzung überschreiten, mit xz nicht dekomprimiert werden.

Die LZMA-Utils erzeugen nur .lzma-Dateien mit einer Wörterbuchgröße von 2^n (einer Zweierpotenz), aber akzeptieren Dateien mit einer beliebigen Wörterbuchgröße. Liblzma akzeptiert nur .lzma-Dateien mit einer Wörterbuchgröße von 2^n oder 2^n + 2^(n-1). Dies dient zum Verringern von Fehlalarmen beim Erkennen von .lzma-Dateien.

Diese Einschränkungen sollten in der Praxis kein Problem sein, da praktisch alle .lzma-Dateien mit Einstellungen komprimiert wurden, die Liblzma akzeptieren wird.

Angehängter Datenmüll

Bei der Dekompression ignorieren die LZMA-Utils stillschweigend alles nach dem ersten .lzma-Datenstrom. In den meisten Situationen ist das ein Fehler. Das bedeutet auch, dass die LZMA-Utils die Dekompression verketteter .lzma-Dateien nicht unterstützen.

Wenn nach dem ersten .lzma-Datenstrom Daten verbleiben, erachtet xz die Datei als beschädigt, es sei denn, die Option --single-stream wurde verwendet. Dies könnte die Ausführung von Skripten beeinflussen, die davon ausgehen, dass angehängter Datenmüll ignoriert wird.

Die komprimierte Ausgabe kann variieren

Die exakte komprimierte Ausgabe, die aus der gleichen unkomprimierten Eingabedatei erzeugt wird, kann zwischen den Versionen der XZ-Utils unterschiedlich sein, selbst wenn die Kompressionsoptionen identisch sind. Das kommt daher, weil der Kodierer verbessert worden sein könnte (hinsichtlich schnellerer oder besserer Kompression), ohne das Dateiformat zu beeinflussen. Die Ausgabe kann sogar zwischen verschiedenen Programmen der gleichen Version der XZ-Utils variieren, wenn bei der Erstellung des Binärprogramms unterschiedliche Optionen verwendet wurden.

Sobald --rsyncable implementiert wurde, bedeutet das, dass die sich ergebenden Dateien nicht notwendigerweise mit Rsync abgeglichen werden können, außer wenn die alte und neue Datei mit der gleichen xz-Version erzeugt wurden. Das Problem kann beseitigt werden, wenn ein Teil der Encoder-Implementierung eingefroren wird, um die mit Rsync abgleichbare Ausgabe über xz-Versionsgrenzen hinweg stabil zu halten.

Eingebettete .xz-Dekompressoren

Eingebettete .xz-Dekompressor-Implementierungen wie XZ Embedded unterstützen nicht unbedingt Dateien, die mit anderen Integritätsprüfungen (Prüfung-Typen) als none und crc32 erzeugt wurden. Da --check=crc64 die Voreinstellung ist, müssen Sie --check=none oder --check=crc32 verwenden, wenn Sie Dateien für eingebettete Systeme erstellen.

Außerhalb eingebetteter Systeme unterstützen die Dekompressoren des .xz-Formats alle Prüfung-Typen oder sind mindestens in der Lage, die Datei zu dekomprimieren, ohne deren Integrität zu prüfen, wenn die bestimmte Prüfung nicht verfügbar ist.

XZ Embedded unterstützt BCJ-Filter, aber nur mit dem vorgegebenen Startversatz.

Grundlagen

Komprimiert die Datei foo mit der Standard-Kompressionsstufe (-6) zu foo.xz und entfernt foo nach erfolgreicher Kompression:

xz foo

bar.xz in bar dekomprimieren und bar.xz selbst dann nicht löschen, wenn die Dekompression erfolgreich war:

xz -dk bar.xz

baz.tar.xz mit der Voreinstellung -4e (-4 --extreme) erzeugen, was langsamer ist als die Vorgabe -6, aber weniger Speicher für Kompression und Dekompression benötigt (48 MiB beziehungsweise 5 MiB):

tar cf - baz | xz -4e > baz.tar.xz

Eine Mischung aus komprimierten und unkomprimierten Dateien kann mit einem einzelnen Befehl dekomprimiert in die Standardausgabe geschrieben werden:

xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt

Parallele Kompression von vielen Dateien

Auf GNU- und *BSD-Systemen können find(1) und xargs(1) zum Parallelisieren der Kompression vieler Dateien verwendet werden:

find . -type f \! -name '*.xz' -print0 \
    | xargs -0r -P4 -n16 xz -T1

Die Option -P von xargs(1) legt die Anzahl der parallelen xz-Prozesse fest. Der beste Wert für die Option -n hängt davon ab, wie viele Dateien komprimiert werden sollen. Wenn es sich nur um wenige Dateien handelt, sollte der Wert wahrscheinlich 1 sein; bei Zehntausenden von Dateien kann 100 oder noch mehr angemessener sein, um die Anzahl der xz-Prozesse zu beschränken, die xargs(1) schließlich erzeugen wird.

Die Option -T1 für xz dient dazu, den Einzelthread-Modus zu erzwingen, da xargs(1) zur Steuerung des Umfangs der Parallelisierung verwendet wird.

Roboter-Modus

Berechnen, wie viel Byte nach der Kompression mehrerer Dateien insgesamt eingespart wurden:

xz --robot --list *.xz | awk '/^totals/{print $5-$4}'

Ein Skript könnte abfragen wollen, ob es ein xz verwendet, das aktuell genug ist. Das folgende sh(1)-Skript prüft, ob die Versionsnummer des Dienstprogramms xz mindestens 5.0.0 ist. Diese Methode ist zu alten Beta-Versionen kompatibel, welche die Option --robot nicht unterstützen:

if ! eval "$(xz --robot --version 2> /dev/null)" ||
        [ "$XZ_VERSION" -lt 50000002 ]; then
    echo "Your xz is too old."
fi
unset XZ_VERSION LIBLZMA_VERSION

Eine Speicherbedarfsbegrenzung für die Dekompression mit XZ_OPT setzen, aber eine bereits gesetzte Begrenzung nicht erhöhen:

NEWLIM=$((123 << 20))  # 123 MiB
OLDLIM=$(xz --robot --info-memory | cut -f3)
if [ $OLDLIM -eq 0 -o $OLDLIM -gt $NEWLIM ]; then
    XZ_OPT="$XZ_OPT --memlimit-decompress=$NEWLIM"
    export XZ_OPT
fi

Benutzerdefinierte Filterketten für die Kompression

Der einfachste Anwendungsfall für benutzerdefinierte Filterketten ist die Anpassung von LZMA2-Voreinstellungsstufen. Das kann nützlich sein, weil die Voreinstellungen nur einen Teil der potenziell sinnvollen Kombinationen aus Kompressionseinstellungen abdecken.

Die KompCPU-Spalten der Tabellen aus den Beschreibungen der Optionen -0 … -9 und --extreme sind beim Anpassen der LZMA2-Voreinstellungen nützlich. Diese sind die relevanten Teile aus diesen zwei Tabellen:

Wenn Sie wissen, dass eine Datei für eine gute Kompression ein etwas größeres Wörterbuch benötigt (zum Beispiel 32 MiB), aber Sie sie schneller komprimieren wollen, als dies mit xz -8 geschehen würde, kann eine Voreinstellung mit einem niedrigen KompCPU-Wert (zum Beispiel 1) dahingehend angepasst werden, ein größeres Wörterbuch zu verwenden:

xz --lzma2=preset=1,dict=32MiB foo.tar

Mit bestimmten Dateien kann der obige Befehl schneller sein als xz -6, wobei die Kompression deutlich besser wird. Dennoch muss betont werden, dass nur wenige Dateien von einem größeren Wörterbuch profitieren, wenn der KompCPU-Wert niedrig bleibt. Der offensichtlichste Fall, in dem ein größeres Wörterbuch sehr hilfreich sein kann, ist ein Archiv, das einander sehr ähnliche Dateien enthält, die jeweils wenigstens einige Megabyte groß sind. Das Wörterbuch muss dann deutlich größer sein als die einzelne Datei, damit LZMA2 den größtmöglichen Vorteil aus den Ähnlichkeiten der aufeinander folgenden Dateien zieht.

Wenn hoher Speicherbedarf für Kompression und Dekompression kein Problem ist und die zu komprimierende Datei mindestens einige Hundert Megabyte groß ist, kann es sinnvoll sein, ein noch größeres Wörterbuch zu verwenden, als die 64 MiB, die mit xz -9 verwendet werden würden:

xz -vv --lzma2=dict=192MiB big_foo.tar

Die Verwendung von -vv (--verbose --verbose) wie im obigen Beispiel kann nützlich sein, um den Speicherbedarf für Kompressor und Dekompressor zu sehen. Denken Sie daran, dass ein Wörterbuch, das größer als die unkomprimierte Datei ist, Speicherverschwendung wäre. Daher ist der obige Befehl für kleine Dateien nicht sinnvoll.

Manchmal spielt die Kompressionszeit keine Rolle, aber der Speicherbedarf bei der Dekompression muss gering gehalten werden, zum Beispiel um die Datei auf eingebetteten Systemen dekomprimieren zu können. Der folgende Befehl verwendet -6e (-6 --extreme) als Basis und setzt die Wörterbuchgröße auf nur 64 KiB. Die sich ergebende Datei kann mit XZ Embedded (aus diesem Grund ist dort --check=crc32) mit nur etwa 100 KiB Speicher dekomprimiert werden.

xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo

Wenn Sie so viele Byte wie möglich herausquetschen wollen, kann die Anpassung der Anzahl der literalen Kontextbits (lc) und der Anzahl der Positionsbits (pb) manchmal hilfreich sein. Auch die Anpassung der Anzahl der literalen Positionsbits (lp) könnte helfen, aber üblicherweise sind lc und pb wichtiger. Wenn ein Quellcode-Archiv zum Beispiel hauptsächlich ASCII-Text enthält, könnte ein Aufruf wie der folgende eine etwas kleinere Datei (etwa 0,1 %) ergeben als mit xz -6e (versuchen Sie es auch lc=4):

xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar

Die Verwendung eines anderen Filters mit LZMA2 kann die Kompression bei verschiedenen Dateitypen verbessern. So könnten Sie eine gemeinsam genutzte Bibliothek der Architekturen x86-32 oder x86-64 mit dem BCJ-Filter für x86 komprimieren:

xz --x86 --lzma2 libfoo.so

Beachten Sie, dass die Reihenfolge der Filteroptionen von Bedeutung ist. Falls --x86 nach --lzma2 angegeben wird, gibt xz einen Fehler aus, weil nach LZMA2 kein weiterer Filter sein darf und auch weil der BCJ-Filter für x86 nicht als letzter Filter in der Filterkette gesetzt werden darf.

Der Delta-Filter zusammen mit LZMA2 kann bei Bitmap-Bildern gute Ergebnisse liefern. Er sollte üblicherweise besser sein als PNG, welches zwar einige fortgeschrittene Filter als ein simples delta bietet, aber für die eigentliche Kompression »Deflate« verwendet.

Das Bild muss in einem unkomprimierten Format gespeichert werden, zum Beispiel als unkomprimiertes TIFF. Der Abstandsparameter des Delta-Filters muss so gesetzt werden, dass er der Anzahl der Bytes pro Pixel im Bild entspricht. Zum Beispiel erfordert ein 24-Bit-RGB-Bitmap dist=3, außerdem ist es gut, pb=0 an LZMA2 zu übergeben, um die 3-Byte-Ausrichtung zu berücksichtigen:

xz --delta=dist=3 --lzma2=pb=0 foo.tiff

Wenn sich mehrere Bilder in einem einzelnen Archiv befinden (zum Beispiel .tar), funktioniert der Delta-Filter damit auch, sofern alle Bilder im Archiv die gleiche Anzahl Bytes pro Pixel haben.