Ist es möglich, die komprimierten und unkomprimierten Größen einer Datei auf einem btrfs-Dateisystem?

Ist es möglich, zu bestimmen, was die komprimierte Größe (ich nehme an, das ist das, was aufgelistet ist ls -l) und unkomprimierte Größe der Dateien auf eine btrfs Dateisystem mit transparente Kompression aktiviert?

  • ls -l zeigen Sie die unkomprimierte Größe, nicht die komprimierte Größe.
  • Danke, gut zu wissen. Dann, wie kann ich die komprimierte Größe?
  • Keine Ahnung. Meine Vermutung müsste man die Blöcke (vielleicht über filefrag), aber es ist nicht wirklich mein Gebiet. Diese Frage ist wohl eher angebracht, die auf super-user als stack-überlauf, aber TBH, ich würde versuchen, eine btrfs-forum statt (wie IRC-Raum oder auf der mailing-Liste).
InformationsquelleAutor gandalf3 | 2013-10-20
  1. 17

    gibt es Drittanbieter-Tools, die das können.

    https://github.com/kilobyte/compsize

    Verwendung:

    ayush@devbox:/code/compsize$ sudo compsize /opt
Processed 54036 files, 42027 regular extents (42028 refs), 27150 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
Data        82%      5.3G         6.4G         6.4G       
none       100%      4.3G         4.3G         4.3G       
zlib        37%      427M         1.1G         1.1G       
lzo         56%      588M         1.0G         1.0G
    • Dies ist die richtige Antwort, es ist mehr beteiligt, diese Ausführung zu erhalten. Auf SuSE Linux Sprung 42.3 ich hatte mit der Installation der libbtrfs-devel-Paket zu bekommen, es zu kompilieren, aber dann hat es Super geklappt!
    InformationsquelleAutor Ayush
  2. 7

    Ich bin nicht in der Lage zu Antworten auf eine Datei vom Datei-basis, und @catlover2 gab die Antwort für ein Dateisystem. Aber man sollte unterscheiden zwischen der block-Größe auf der Festplatte und die Größe in der (virtuellen) Dateisystem ls und du können nicht über das hinausgehen, Dateisystem, so geben Sie keine Informationen an, wie viele Datenträger-Blöcke verwendet, und @jiliagre --apparent-size ist hier nutzlos.

    Zur besseren Veranschaulichung dieser Frage, ich habe einen test mit einem einzigen 23G-Datei btrfs-Dateisystem; zuerst entpackt, dann mit lzo komprimiert. Die Beispiel-Datei ist das abbild einer virtuellen Maschine und als nur eine Kompression Niveau von 0.5. Es zeigt sich, dass nur df, und btrfs filesystem df zeigen kann, ist die Kompression.

    $   lvcreate vg0 test_btrfs -L 30G
Logical volume "test_btrfs" created
$ mkfs.btrfs /dev/vg0/test_btrfs
...
fs created label (null) on /dev/vg0/test_btrfs
    nodesize 16384 leafsize 16384 sectorsize 4096 size 30.00GiB
$ mount /dev/vg0/test_btrfs /tmp/test_btrfs
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=8.00MiB, used=256.00KiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=112.00KiB
Metadata, single: total=8.00MiB, used=0.00
$ cp bigfile /tmp/test_btrfs
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=24.01GiB, used=22.70GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=23.64MiB
Metadata, single: total=8.00MiB, used=0.00
$ btrfs filesystem df /tmp/test_btrfs
... unchanged!
$ cd /tmp/test_btrfs/
$ ls -l bigfile
-rw------- 1 root root 24367940096 May  4 15:03 bigfile
$ du -B1 --apparent-size bigfile
24367940096 bigfile
$ du -B1 bigfile
24367943680 bigfile
$ btrfs filesystem defragment -c bigfile
$ ls -l bigfile
-rw------- 1 root root 24367940096 May  4 15:03 bigfile
$ du -B1 --apparent-size bigfile
24367940096 bigfile
$ du -B1 bigfile
24367943680 bigfile
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=24.01GiB, used=12.90GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=39.19MiB
Metadata, single: total=8.00MiB, used=0.00
$ df -BG /tmp/test_btrfs
Filesystem                 1G-blocks  Used Available Use% Mounted on
/dev/mapper/vg0-test_btrfs       30G   13G       16G  47% /tmp/test_btrfs

    Die Frage von @gandalf3 ist noch immer unbeantwortet, und vielleicht werden wir warten müssen, für die Entwicklung von btrfs (oder zu helfen, Sie zu entwickeln!) um eine ordnungsgemäße zugrunde liegenden Datenträger-block du für eine Besondere Datei. Es wäre sehr nützlich, finde ich sehr frustrierend, wenn ich mount für eine btrfs-fs mit Kompression (ohne Kraft) nicht wissen, ob meine Dateien komprimiert sind oder nicht und auf welcher Ebene.

    InformationsquelleAutor marcz
  3. 2

    Des on-disk-Größe einer Datei, unabhängig von der Datei-system-Typ, gegeben ist1 von der du Befehl, zB:

    $ du -h *
732K    file
512 file1
4.0M    file2
$ du -B1 *
749568  file
512 file1
4091904 file2

    Des on-disk-Größe ist gleich der Größe der Datei und die Größe der zugehörigen Metadaten, gerundet auf die Blockgröße des Dateisystems. Nicht komprimierte Dateien haben in der Regel ein etwas größeres auf der Festplatte Größe als die tatsächliche (Byte count) Größe.

    Wie gesagt, die unkomprimierte Größe wird durch ls -l. Es kann auch berichtet werden du mit der --apparent-size option;

    $ du --apparent-size -h *
826K    file
64M file1
17M file2
$ du --apparent-size -B 1  *
845708  file
67108864    file1
16784836    file2

    Beachten Sie, dass -B1 und --apparent-size sind GNU-spezifische du extensions.

    1 Es scheint btrfs folgt nicht dieser Regel. Wenn das wirklich/noch stimmt, mein Verständnis ist, die berücksichtigt werden sollten einen Fehler oder zumindest eine POSIX-non-conformance.

    • btrfs liegt du über die on-disk Größe 🙁
    • Es ist kein bug, siehe den Eintrag in das Btrfs-FAQ mit dem Titel: "Warum nicht du Bericht die komprimierte Größe?" Beispiel: Es gibt Dienstprogramme, die bestimmen, Kargheit einer Datei durch den Vergleich der nominal-und block-zugewiesene Größe, die dieses Verhalten verursachen Fehler, wenn st_blocks enthalten der Betrag nach der Kompression.
    • Ok, kein bug, denn es ist nicht ein gebrochenes Umsetzung, sondern eine design-Entscheidung. Es ist immer noch ein non conformance to POSIX-und, IMHO, ein design-Fehler mit einer irrigen Erklärung: Dies wurde getan, um nicht zu brechen gefälschte Programme von Drittanbietern, aber ignorieren die Tatsache, es zu tun, bricht nicht gefälschte Programme, die erwarten, dass ein verlässlicher Wert in st_blocks. Was "number of disk blocks" bedeutet, ist klar, und btrfs nicht entsprechen dieser definition.
    • Die Funktion wird als transparente Kompression. Wenn die Größe zeigen würde, die komprimierte Größe, es wäre nicht sehr durchsichtig, jetzt wäre es ?
    InformationsquelleAutor jlliagre
  4. 1

    Ich war versucht, diese Frage zu beantworten, auch, und hier ist, was ich gefunden habe:du -s und df produzieren verschiedene zahlen. Also ich habe einige Tests:

    1. Habe ich ein test-Verzeichnis in /home mit einer Größe von über 3 TB. Es ist eine teilweise Kopie des gesamten /home-Verzeichnis mit einer typischen Mischung von Dokumenten, text-Dateien, Bilder und Programme

    2. Ich komprimiert dieses Verzeichnis mit .tar.gz das führte in der Datei der Größe

    # du -s ./test.tar.gz
    1672083116 ./test.tar.gz

    1. Mit dieser Datei vorhandenen in der Datei system habe ich dieses:

    # du -s /home
    11017624664 /home

    # du --apparent-size -s /home
    11010709168 /home

    # df /home
    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/md2 31230406656 9128594488 22095200200 30% /home

    Was bedeutet, dass wir ((11017624664/(1024**2))/(9128594488/(1024**2))-1)*100 = 20% Verdichtung

    1. dann habe ich diese Datei gelöscht und ich habe diese:

    # du -s /home
    9348284812 /home

    # du --apparent-size -s /home
    9340957158 /home

    # df /home
    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/md2 31230406656 7455549036 23764949364 24% /home

    Woraus sich ein Komprimierungsverhältnis von 25%. Auch aus diesen Informationen habe ich festgestellt, dass die test.tar.gz Datei mit dem real-Größe 1592 G belegt auf der Festplatte 1595 G. Auch habe ich festgestellt, dass die Verwendung --apparent-size Flagge produziert unbedeutenden Unterschied, wahrscheinlich aufgrund der Blockgröße Rundung.

    Side note, meine fstab Zeile für das mounten der partition ist:

    UUID=be6...07fe /home btrfs defaults,compress=zlib 0 2

    Zusammenfassung:

    Prüfen, Kompression Verhältnis auf den ganzen partition-verwenden Sie diese beiden Befehle:

    du -s /home
    df /home

    Dann teilen Sie die Ausgänge. Ich denke, dass meine 25% Kompression Verhältnis ist ein typisches Ergebnis zu erwarten von einem zlib Kompressor.

    InformationsquelleAutor cosurgi
  5. 1

    Können Sie erstellen Sie ein Btrfs-Dateisystem in einer Datei, mounten, kopieren Sie die Dateien und führen Sie df:

    $ dd if=/dev/zero of=btrfs.data size=1M count=1K
$ mkdir btrfs
$ mount btrfs.data btrfs -o compress
... copy the files to ./btrfs
$ sync
$ cd btrfs
$ btrfs filesystem df .

    Beispiel einer einzelnen Datei komprimiert aus 17MiB zu 5MiB:

    $ cd btrfs
$ ls -l
-rwx------ 1 atom atom 17812968 Oct 27  2015 commands.bin
$ btrfs filesystem df .
Data, single: total=1.01GiB, used=5.08MiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B
    InformationsquelleAutor atomsymbol
  6. 1

    In Ubuntu-18

    apt install btrfs-compsize
compsize /mnt/btrfs-partition
    InformationsquelleAutor Dmytro Gierman
  7. -5

    Laufen btrfs filesystem df /mountpoint.

    Beispiel-Ausgabe:

    Data: total=2.01GB, used=1.03GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.00GB, used=2.52MB
Metadata: total=8.00MB, used=0.00

    Den Schlüssel Zeile beginnt mit Data:; used= ist die komprimierte Größe und total= ist die Gesamtgröße, als ob auf ein Unkomprimiertes Dateisystem. Ich erstellte eine test-Dateisystem, montiert es mit der compress_force=zlib option, und kopiert 1GB von Nullen in eine Datei auf dem Dateisystem, an diesem Punkt der Data: Linie war Data: total=1.01GB, used=32.53MB (Nullen sind ganz komprimierbar!). Dann habe ich wieder montiert das Dateisystem mit Komprimierung deaktiviert, kopiert ein anderes GB Nullen zu, und an diesem Punkt der Data: Zeile Lesen Data: total=2.01GB, used=1.03GB.

    Als nemequ oben erwähnt, ls -l im Gegenteil, zeigt die unkomprimierte Größe.

    • Das ist nicht, was dies bedeutet. Das bedeutet, dass zwei Blöcke (1 GB) verwendet, sondern nur 1.03 GB verwendet werden. Dies nur erlaubt, Sie zu sehen, die nicht komprimierte Größe am Anfang, da die vorhandene Größe 0
    • -1 Diese Antwort ist schlichtweg falsch und basiert auf falschen Annahmen. total= nicht quantifizieren, Daten-Nutzung. Btrfs behält sich große Ansammlungen von leeren Raum im Voraus: dies verbessert die Daten-Lokalität und reduziert die Fragmentierung. total quantifiziert die Summe der aktuellen chunks, das heißt, dass used + die Summe der leere Raum in den Blöcken. Wenn Sie schreiben und es ist genug freier Speicherplatz im chunk used verpasst, aber total nicht. Wenn used Ansätze total, Btrfs legt einen neuen Platzhalter über einige Raum außerhalb total, fügt es zu total, und nicht touch used.
    • Siehe auch : blogs.oracle.com/wim/entry/btrfs_compression
    InformationsquelleAutor catlover2
Schreibe einen Kommentar