"du" auf XFS gibt falsche Dateigröße an

[Daniel Meszaros]

Hallo,

ich wundere mich gerade und hoffe, dass Ihr mir ggf. auf die Sprünge
helfen könnt. Ich habe zwei Maschinen: Maschine 1 mit einem XFS-Storage
und Maschine 2 mit GFS2. Ich ziehe gerade Daten von Maschine 1 zu
Maschine 2 um.

Es handelt sich um KVM-Images. Die Images werden per SCP kopiert,
während der KVM-Gast ausgeschaltet ist. Sobald ein Gast umgezogen ist,
starte ich ihn auf Maschine 2 - bei unserem Beispiel hier ist
"mailhelper" also bereits auf Maschine 2 aktiv - das Image war/ist also
sowohl auf der Quelle als auch auf dem Ziel funktionstüchtig.

Beim Check mit "du" bekomme ich ein merkwürdiges Ergebnis. Könnte es
sein, dass "du" nicht mit XFS harmoniert? Wenn ja, gibt es Alternativen?

Maschine 1:
# ls -al mailhelper/
insgesamt 3376628
drwxr-sr-x 2 root vmusers 27 9. Jun 14:15 .
drwxr-sr-x 14 root vmusers 4096 1. Aug 14:40 ..
-rwxr-xr-x 1 root root 10737418240 3. Aug 09:26 mailhelper.img
# du -h --max-depth=1 mailhelper/
3,3G mailhelper/

Maschine 2:
# ls -al mailhelper/
insgesamt 10506420
drwxr-xr-x 2 root root 0 3. Aug 09:27 .
drwxr-xr-x 9 root root 0 3. Aug 09:26 ..
-rwxr-xr-x 1 libvirt-qemu kvm 10737418240 3. Aug 09:49 mailhelper.img
# du -h --max-depth=1 mailhelper/
11G mailhelper/

CU,
Mészi.

[David Raab]

Post by Daniel Meszaros
Beim Check mit "du" bekomme ich ein merkwürdiges Ergebnis. Könnte es
sein, dass "du" nicht mit XFS harmoniert? Wenn ja, gibt es Alternativen?

"du" zeigt den Verbrauch auf der Festplatte an, und das muss nicht die
Dateigröße sein. Durch sogenannte Sparse-Dateien werden Leere Blöcke in
Dateien zum Beispiel einfach ausgelassen, und eine Datei wächst nur dann
wenn man in diesem Bereich schreibt.

Wenn du die Datei dann mit *scp* kopierst werden die Leere bereiche aber
wirklich aufgelöst so das das Endresultat wirklich die volle größe ist.

Ein Beispiel, wenn du das Image so angelegt hast.

Post by Daniel Meszaros
Formatting 'test', fmt=raw size=2147483648
-rw-r--r-- 1 sidburn sidburn 2147483648 Aug 3 10:17 test
0 test
0 total

Dann wurden die 2 GB noch nicht auf der festplatte alloziert, daher ist
die eigentliche größe der Datei noch 0 Bytes. "du" gibt immer die Größe
auf der festplatte aus, was etwas anderes als die Dateigröße ist,
nebenbei angemerkt.

Besser ist es du allozierst den Festplattenspeicher übrigens sofort.
Dadurch wird die Fragmentierung verringert was später im gast doch
extrem langsam werden kann. Ich nutze für Gäste aber LVM was ich
nochmals für deutlich besser halte als Disk Images anzulegen.

[Martin Steigerwald]

Post by David Raab

Post by Daniel Meszaros
Beim Check mit "du" bekomme ich ein merkwürdiges Ergebnis. Könnte es
sein, dass "du" nicht mit XFS harmoniert? Wenn ja, gibt es
Alternativen?

"du" zeigt den Verbrauch auf der Festplatte an, und das muss nicht die
Dateigröße sein. Durch sogenannte Sparse-Dateien werden Leere Blöcke in
Dateien zum Beispiel einfach ausgelassen, und eine Datei wächst nur
dann wenn man in diesem Bereich schreibt.
Wenn du die Datei dann mit *scp* kopierst werden die Leere bereiche
aber wirklich aufgelöst so das das Endresultat wirklich die volle
größe ist.

rsync -S oder --sparse kopiert die Datei mit den Löchern.

Die Löcher lassen sich mit filefrag -v sehen:

***@merkaba:~/Amiga> sudo filefrag -v Messages.hardfile
[sudo] password for martin:
Filesystem type is: ef53
File size of Messages.hardfile is 1073741824 (262144 blocks, blocksize
4096)
ext logical physical expected length flags
0 0 9023488 2339
1 2691 9026179 9025826 32125
2 34816 9058304 32768
3 67584 9091072 32768
4 100352 9123840 2048
5 102400 9127936 9125887 32768
6 135168 9160704 32768
7 167936 9193472 14336
8 182272 9209856 9207807 3892
9 262143 9273344 9213747 1 eof
Messages.hardfile: 5 extents found

Hier ist zum Beispiel ein Loch zwischen Extent 8 und 9. Da 182272 + 3892
eben nicht 262143 ergibt ;).

Post by David Raab
Ein Beispiel, wenn du das Image so angelegt hast.

Post by Daniel Meszaros
Formatting 'test', fmt=raw size=2147483648
-rw-r--r-- 1 sidburn sidburn 2147483648 Aug 3 10:17 test
0 test
0 total

Dann wurden die 2 GB noch nicht auf der festplatte alloziert, daher ist
die eigentliche größe der Datei noch 0 Bytes. "du" gibt immer die Größe
auf der festplatte aus, was etwas anderes als die Dateigröße ist,
nebenbei angemerkt.
Besser ist es du allozierst den Festplattenspeicher übrigens sofort.
Dadurch wird die Fragmentierung verringert was später im gast doch
extrem langsam werden kann. Ich nutze für Gäste aber LVM was ich
nochmals für deutlich besser halte als Disk Images anzulegen.

Oder mit fallocate. Fallocate belegt die Extents, beschreibt sie aber
nicht:

***@merkaba:~/Zeit> fallocate -l 1G testdatei
***@merkaba:~/Zeit> sudo filefrag -v testdatei
Filesystem type is: ef53
File size of testdatei is 1073741824 (262144 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 45056000 32758 unwritten
1 32758 7766016 45088757 32758 unwritten
2 65516 7798784 7798773 32758 unwritten
3 98274 7831552 7831541 32758 unwritten
4 131032 7929856 7864309 32758 unwritten
5 163790 7995392 7962613 32758 unwritten
6 196548 10223616 8028149 32758 unwritten
7 229306 10256384 10256373 32758 unwritten
8 262064 10312960 10289141 80 unwritten,eof
testdatei: 9 extents found

Solange die Partition mit den Images je nach Größe noch mindestens 5-20%
Speicher frei hat, sollte es eigentlich keine allzugroße Probleme mit
Fragmentierung geben. Moderene Dateisystem fragmentieren kaum, wenn sie
genügend freien Speicher haben. Das ist zumindest meine Erfahrung.

Ciao,

[David Raab]

Post by Martin Steigerwald
Solange die Partition mit den Images je nach Größe noch mindestens 5-20%
Speicher frei hat, sollte es eigentlich keine allzugroße Probleme mit
Fragmentierung geben. Moderene Dateisystem fragmentieren kaum, wenn sie
genügend freien Speicher haben. Das ist zumindest meine Erfahrung.

Leider schon, gab ja auch hier schon einige auf der Mailingliste wo das
booten eines gastes teilweise etliche minuten dauerte. Das Problem ist
eine doppelte Fragmentierung.

Das OS selber fragmentiert die datei, aber es ist ja ein disk-image. Und
das darauf laufende OS fragmentiert hier nochmals. Auf Disk-Images für
Gäste hat dies eine große auswirkung wenn du den Gast länger nutzt.

Daher auch lieber LVM für Gäste. Das hat auch generell nicht so einen
großen overhead wie eine Datei da es einfach nur ein Blockdevice ist.

[Martin Steigerwald]

Post by David Raab

Post by Martin Steigerwald
Solange die Partition mit den Images je nach Größe noch mindestens
5-20% Speicher frei hat, sollte es eigentlich keine allzugroße
Probleme mit Fragmentierung geben. Moderene Dateisystem
fragmentieren kaum, wenn sie genügend freien Speicher haben. Das ist
zumindest meine Erfahrung.

Leider schon, gab ja auch hier schon einige auf der Mailingliste wo das
booten eines gastes teilweise etliche minuten dauerte. Das Problem ist
eine doppelte Fragmentierung.
Das OS selber fragmentiert die datei, aber es ist ja ein disk-image.
Und das darauf laufende OS fragmentiert hier nochmals. Auf Disk-Images
für Gäste hat dies eine große auswirkung wenn du den Gast länger
nutzt.
Daher auch lieber LVM für Gäste. Das hat auch generell nicht so einen
großen overhead wie eine Datei da es einfach nur ein Blockdevice ist.

Nun, das ist natürlich schon auch ein spezieller Workload.

Ich habs bislang auch mit VM-Images noch nicht erlebt, aber ich verwende
Virtualisierung unter Linux nur selten. Und VMware ESX auf NetApp NFS, was
wir in der Firma produktiv nutzen, ist ja nochmal ein anderes Setup.

[frank paulsen]

Post by David Raab
Das OS selber fragmentiert die datei, aber es ist ja ein disk-image. Und
das darauf laufende OS fragmentiert hier nochmals. Auf Disk-Images für
Gäste hat dies eine große auswirkung wenn du den Gast länger nutzt.
Daher auch lieber LVM für Gäste. Das hat auch generell nicht so einen
großen overhead wie eine Datei da es einfach nur ein Blockdevice ist.

das ist eine reichlich komische sichtweise. ob das image in einem
filesystem fragmentiert vorliegt, oder auf einem LVM genauso
fragmentiert vorliegt, haengt einzig und allein davon ab, wie vor dem
einspielen der freie platz vorlag.

'deutliche weniger' overhead hat LVM in der praxis auch nicht, wenn man
ein dateisystem hat, das mit 'grossen' dateien vernuenftig umgeht, xfs
ist ein beispiel dafuer.

[David Raab]

Post by frank paulsen
das ist eine reichlich komische sichtweise. ob das image in einem
filesystem fragmentiert vorliegt, oder auf einem LVM genauso
fragmentiert vorliegt, haengt einzig und allein davon ab, wie vor dem
einspielen der freie platz vorlag.

Da das Image selber dynamisch wächst kommt es unweigerlich zur
Fragmentierung. Abhelfen würde es wenn man natürlich das Dateiimage für
den gast vorher vollständig alloziert, was ich auch empfehlen würde,
dann entsteht hier wohl weniger ein Problem.

[Daniel Meszaros]

Post by David Raab
Da das Image selber dynamisch wächst kommt es unweigerlich zur
Fragmentierung. Abhelfen würde es wenn man natürlich das Dateiimage
für den gast vorher vollständig alloziert, was ich auch empfehlen
würde, dann entsteht hier wohl weniger ein Problem.

Mal eine ggf. dämliche Frage: HFS+ und NTFS fragmentieren ja auch nicht,
wenn man den Parolen der Hersteller glauben schenken will. Trotzdem
finden Defragmentierer reißenden Absatz und erzeugen Leistungszuwächse,
die nicht immer nur eingebildet sind. Ergo -und Ihr bestätigt es ja auch
in der Diskussion- existiert Fragmentierung auf allen Filesystemen. Und
dennoch gibt es unter Linux keine Filesystem-Defragmentierer? :-/

CU,
Mészi.

[David Raab]

Post by Daniel Meszaros
Mal eine ggf. dämliche Frage: HFS+ und NTFS fragmentieren ja auch nicht,
wenn man den Parolen der Hersteller glauben schenken will. Trotzdem
finden Defragmentierer reißenden Absatz und erzeugen Leistungszuwächse,
die nicht immer nur eingebildet sind. Ergo -und Ihr bestätigt es ja auch
in der Diskussion- existiert Fragmentierung auf allen Filesystemen. Und
dennoch gibt es unter Linux keine Filesystem-Defragmentierer? :-/

Klar gibt es das. Hängt vom Dateisystem ab. XFS hat beispielsweise
"xfs_fsr". ext3 hat keinen Dateifragmentierer. Ich selber nutze auch
unter anderem deswegen selber XFS. Für ext4 ist einer geplant, aber
glaube ich noch nicht fertig.

Ansonsten wird fragmentierung auf modernen Dateisystemen reduziert, und
nicht jede Fragmentierung ist negativ. Wenn eine 600MB Datei zum
beispiel in 6 Teile aufgesplittet ist, ist diese Fragmentierung
vollkommen unrelevant.

Fragmentierung ist nur dann relevant wenn man sehr viele Fragmente für
kleine Dateien besitzt. Aber auch das ist möglich. Ich hatte unter
Debian Lenny mal ein Torrent Programm das anscheind schlecht
programmiert war und millionen von fragmente erzeugt hatte. *filefrag*
hatte dort selbst für 170MB Dateien Millionen von Fragmente und der
lesespeed der datei lag auf ext3 (damals noch genutzt) dann bei ca. 70
kbyte/sec.

Bei ext3 reicht dann ein kopieren der Datei(en) womit die Fragmentierung
dann aufgehoben wird. Was aber in der Regel bei jedem Dateisystem hilft.

Ansonsten fragmentieren in diesem Sinne alle Dateisysteme. Nur ist
Fragmentierung nicht automatisch schlecht. Und die modernen Dateisysteme
reduzieren eine schädliche Fragmentierung. Aber ab 90% oder mehr
genutzten Speicher auf einer Partition beginnt jedes Dateisystem mit
einer schädlichen fragmentierung.

Ansonsten hängt es auch von der Applikation ab die du nutzt. Und wenn du
ein Gast-Image nicht vollständig preallozierst wird es sehr stark
fragmentieren. Den ein komplettes Gast Image sagen wir 10GB hat dann
löcher. Der Gast nutzt diese 10GB wie ein vollständiges Stück, und die
Dateisysteme lassen hier auch in der regel freiräume nach dateien so das
diese wachsen kann, daher auf dem Host bedeutet es das dann immer nach
und nach teile nicht anereinanderhängend auf dem Host erzeugt werden. Je
länger du den gast nutzt, desto höher wird die Fragmentierung werden.

Preallozierung kann hier deutlich helfen. Aber noch besser für Disk
Performance ist halt LVM, da du damit ein Blockdevice durchreichst.
Während bei einer Image datei eben eine datei durchgereicht wird, die
wiederrum auf einem Dateisystem liegt.

Fragmentierung gibt es so auch auf Linux Systemenen und auf dessen
Dateisystemen. Wer das nicht wahrhaben will ist einfach noch ein Linux
fanboy und hat sich damit noch nicht so genau beschäftigt ;) Und sucht
irgendwelche Argumente warum GNU/Linux besser als Windows ist.

Aber wie bereits gesagt, bei Modernen Systemen generell ist
Fragmentierung nicht so schädlich wie man meint. Du hast beispielsweise
heutzutage ein Multi-Tasking Dateisystem das sowieso mehrere Dateien
gleichzeitig offen hat zum lesen/schreiben. Daher das OS wird sowieso
nie eine große Datei an einem Stück auslesen, die zeiten von MS-DOS sind
da schon lange vorbei. Und es gibt ja noch die I/O-Scheduler die
versuchen möglichst effizent dateien auszulesen, oder ebend das OS
selber das durch prefetching buffern/cachen die performance ausbessert.

Nur darf die Fragmentierung halt nicht zu groß relativ zur Dateigröße sein.

[Sven Joachim]

Post by Daniel Meszaros
Hallo,
ich wundere mich gerade und hoffe, dass Ihr mir ggf. auf die Sprünge
helfen könnt. Ich habe zwei Maschinen: Maschine 1 mit einem
XFS-Storage und Maschine 2 mit GFS2. Ich ziehe gerade Daten von
Maschine 1 zu Maschine 2 um.
Es handelt sich um KVM-Images. Die Images werden per SCP kopiert,
während der KVM-Gast ausgeschaltet ist. Sobald ein Gast umgezogen ist,
starte ich ihn auf Maschine 2 - bei unserem Beispiel hier ist
"mailhelper" also bereits auf Maschine 2 aktiv - das Image war/ist
also sowohl auf der Quelle als auch auf dem Ziel funktionstüchtig.
Beim Check mit "du" bekomme ich ein merkwürdiges Ergebnis. Könnte es
sein, dass "du" nicht mit XFS harmoniert?

Nein, eher nicht.

Post by Daniel Meszaros
Wenn ja, gibt es Alternativen?

Kein scp verwenden, sondern z.B. NFS und »cp --sparse=auto«. Spart Platz
auf Maschine 2.

Post by Daniel Meszaros
# ls -al mailhelper/
insgesamt 3376628
drwxr-sr-x 2 root vmusers 27 9. Jun 14:15 .
drwxr-sr-x 14 root vmusers 4096 1. Aug 14:40 ..
-rwxr-xr-x 1 root root 10737418240 3. Aug 09:26 mailhelper.img
# du -h --max-depth=1 mailhelper/
3,3G mailhelper/

Die Datei hat Löcher¹ und belegt deswegen weniger Platz als ihre Größe
angibt.

Post by Daniel Meszaros
# ls -al mailhelper/
insgesamt 10506420
drwxr-xr-x 2 root root 0 3. Aug 09:27 .
drwxr-xr-x 9 root root 0 3. Aug 09:26 ..
-rwxr-xr-x 1 libvirt-qemu kvm 10737418240 3. Aug 09:49 mailhelper.img
# du -h --max-depth=1 mailhelper/
11G mailhelper/

Durch das Kopieren mit scp werden die Löcher mit Nullbytes aufgefüllt,
auf Maschine 2 belegt das Image also tatsächlich fast 11 Gigabyte.

Sven


¹ http://de.wikipedia.org/wiki/Sparse-Datei

[Daniel Meszaros]

Hi!

Post by Sven Joachim

Post by Daniel Meszaros
Wenn ja, gibt es Alternativen?

Kein scp verwenden, sondern z.B. NFS und »cp --sparse=auto«. Spart Platz
auf Maschine 2.

Aber um den Preis der Fragmentierung der Imagedatei. :-/

Post by Sven Joachim
Durch das Kopieren mit scp werden die Löcher mit Nullbytes aufgefüllt,
auf Maschine 2 belegt das Image also tatsächlich fast 11 Gigabyte.

Auch wenn es sparsamer erscheint, erlauben die Sparsefiles doch ein
"Überbuchen" des tatsächlich vorhandenen Festplattenspeichers. Wenn ich
es richtig verstehe, sind meine Zieldateien damit keine Sparsefiles
mehr. Ich denke, dann werde ich das Prozedere so beibehalten.

Danke für die Antworten,
Mészi.

[Martin Steigerwald]

Post by Daniel Meszaros
Hi!

Post by Sven Joachim
Durch das Kopieren mit scp werden die Löcher mit Nullbytes
aufgefüllt, auf Maschine 2 belegt das Image also tatsächlich fast 11
Gigabyte.

Auch wenn es sparsamer erscheint, erlauben die Sparsefiles doch ein
"Überbuchen" des tatsächlich vorhandenen Festplattenspeichers. Wenn ich
es richtig verstehe, sind meine Zieldateien damit keine Sparsefiles
mehr. Ich denke, dann werde ich das Prozedere so beibehalten.

Ein Befehl, der Löcher beim Kopieren durch unwritten extents ersetzt, wäre
interessant. Das Schreiben vieler Nullen verlängert den Kopiervorgang und
damit die Downtime des Gastes.

[Paulo Aires]

Sparsefiles:
Das ist deine Antwort auf die Probleme. Die VM muss bei Sparsefiles immer neuen platz beantragen die kostet Zeit, zudem liegen alle Disk-Images auf einem Filesystem wohlmöglich am gleichen Tag angelegt und somit dicht bei einander. Wenn die VM 1 grösser wird, und auf dem nächsten block schreiben möchte ist dieser bereist von der VM2 belegt, und der nächste block wird verwendet.

Wenn du Sparsefiles, verwendes fragmentierst du das Hostsystem sehr stark. Die Disk-Images werden teilchenweise (blöcke) verteilt. z.b. 1. Block VM1, 2. Block VM2, 3.-10.Block VM4 11-12. Block VM3 13-15.Block VM1 etc.

Du solltest Sparsefiles nur für Testumgebungen nutzen wenn du wenig Speicherplatz auf dem Testhost hast.

In produktiven Umgebungen am besten LVM oder Disk-Images welche ohne sparse angelegt werden diese verbrauchen dann tatsächlich die gesammte Größe der Disk auf dem Hostsystem aber dafür kann das Filesystem auf dem Host nicht fragmentieren. Lese und Schreibvorgang werden damit schneller.

Sparsefiles, werden gerne genutzt und jeder admin fällt früher oder später in diese Falle. Die VM ist schneller aufgesetzt, aber das rächts sich schnell.

Bei NFS dürfte das Problem ähnlich sein. bzw. immer dann wenn Dateien auf einem Filesystem anwachsen (was bei einer VM-Disk ständig der fall ist) in dem auch andere Dateien ablegt werden, kommt es früher oder stäter zu Dataifragmenten und das kostet bei Lesevorgang Zeit.

[Martin Steigerwald]

Post by Paulo Aires
Das ist deine Antwort auf die Probleme. Die VM muss bei Sparsefiles
immer neuen platz beantragen die kostet Zeit, zudem liegen alle
Disk-Images auf einem Filesystem wohlmöglich am gleichen Tag angelegt
und somit dicht bei einander. Wenn die VM 1 grösser wird, und auf dem
nächsten block schreiben möchte ist dieser bereist von der VM2 belegt,
und der nächste block wird verwendet.

Auf wen beziehst Du Dich?

unwritten extents via fallocate sind bereits vollständig allozierter, aber
eben nicht mit Nullen beschriebener Platz auf dem Laufwerk.

Wie ich ja auch demonstrierte.

[frank paulsen]

Post by Daniel Meszaros
Beim Check mit "du" bekomme ich ein merkwürdiges Ergebnis. Könnte es
sein, dass "du" nicht mit XFS harmoniert? Wenn ja, gibt es
Alternativen?
# ls -al mailhelper/
insgesamt 3376628
drwxr-sr-x 2 root vmusers 27 9. Jun 14:15 .
drwxr-sr-x 14 root vmusers 4096 1. Aug 14:40 ..
-rwxr-xr-x 1 root root 10737418240 3. Aug 09:26 mailhelper.img
# du -h --max-depth=1 mailhelper/
3,3G mailhelper/

ein sparse-file. das sollte man besser nicht mit 'scp' kopieren, sondern
z.B. mit 'rsync -S'.

'du' gibt dabei den platzverbrauch auf der platte aus, 'ls' die
nominelle groesse.

http://de.wikipedia.org/wiki/Sparse-Datei