Re: "du" auf XFS gibt falsche Dateigröße an
Am Mittwoch, 3. August 2011 schrieb David Raab:
> > 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:
martin@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 ;).
> Ein Beispiel, wenn du das Image so angelegt hast.
>
> > sidburn@sid:~$ kvm-img create test 2G
> > Formatting 'test', fmt=raw size=2147483648
> > sidburn@sid:~$ ll test
> > -rw-r--r-- 1 sidburn sidburn 2147483648 Aug 3 10:17 test
> > sidburn@sid:~$ du -sch 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:
martin@merkaba:~/Zeit> fallocate -l 1G testdatei
martin@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,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: