Konvertierung ext3 -> ext4: extents mit chattr?

[gxyz]

Hallo,

ich bin gerade dabei, diverse Systeme auf Squeeze zu aktualisieren und werde demnächst wohl auch die Dateisysteme von ext3 auf ext4 migrieren. In diesem Zusammenhang bin ich über dieses "Kochrezept" gestolpert:
http://www.debian-administration.org/ar ... filesystem
in dem empfohlen wird, die Dateien mittels "chattr" auf Extents umzustellen. An und für sich fände ich es ganz praktisch, bei der Umstellung auch alte Dateien zu migrieren, allerdings kommt es mir sehr merkwürdig vor, dass dies durch eine schlichte Änderung der Dateiattribute möglich sein sollte, da dafür ja zwangsläufig einiges an Daten reorganisiert werden müsste.

Abgesehen von obigem Dokument konnte ich nichts weiteres zu dem Thema finden -
weiss hier vielleicht jemand genaueres?

[gxyz]

allerdings kommt es mir sehr merkwürdig vor, dass dies durch eine schlichte Änderung der Dateiattribute möglich sein sollte, da dafür ja zwangsläufig einiges an Daten reorganisiert werden müsste

... nachdem ich es gerade 'mal an einer hinreichend großen Datei ausprobiert habe, könnte ich mir vorstellen, daß da wohl doch etwas dran ist - für die schlichte Änderung eines Flags hat die Aktion jedenfalls verdächtig lange gedauert. Wenn ich das auf ein größeres Dateisystem hochrechne (das vermutlich in der Zwischenzeit nur sehr bedingt verwendbar sein dürfte und für den nötigen Filesystemcheck bei der Migration zwansläufig längere Zeit offline wäre) frage ich mich allerdings, ob es dann nicht doch mehr Sinn macht, die Daten aus einem frischen Backup auf einem neu erzeugten Dateisystem wiederherzustellen (dass dann auch garantiert nicht fragmentiert ist - "e4defrag" scheint ja weiterhin nicht in Sicht zu sein ...)

[cosmac]

hi,

allerdings kommt es mir sehr merkwürdig vor, dass dies durch eine schlichte Änderung der Dateiattribute möglich sein sollte, da dafür ja zwangsläufig einiges an Daten reorganisiert werden müsste.

der Kernel macht das tatsächlich so. In fs/ext4/ioctl.c werden die Attribute geändert und wenn 'e' gesetzt wird, ruft er ext4_ext_migrate() aus fs/ext4/migrate.c auf (so war's jedenfalls in 2.6.32).

Der Backup-einspiel-Plan von gxyz scheint mir allerdings auch erwägenswert -- wann testet man schon mal die Restore-Prozedur

[gxyz]

wann testet man schon mal die Restore-Prozedur ;)

... also ich persönlich (nach leidvollen Erfahrungen, versteht sich :-) mindestens 1x/Jahr

[Saxman]

Ich hab das hier mal getestet und

Code: Alles auswählen

find /home -xdev -type f -print0 | xargs -0 chattr +e
find /home -xdev -type d -print0 | xargs -0 chattr +e

auf mein home ausgeführt nachdem es auf einige Verzeichnisse problemlos funktioniert hat.

Resultat, im syslog haufenweise Fehlermeldungen der Art:

Code: Alles auswählen

Jul  7 11:13:00 Leela kernel: [1901267.755109] EXT4-fs error (device dm-2): htree_dirblock_to_tree:586: inode #2: block 127754: comm find: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
Jul  7 11:13:12 Leela kernel: [1901279.369574] EXT4-fs error (device dm-2): htree_dirblock_to_tree:586: inode #2: block 127754: comm find: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
Jul  7 11:13:26 Leela kernel: [1901294.099297] EXT4-fs error (device dm-2): htree_dirblock_to_tree:586: inode #2: block 127754: comm find: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
Jul  7 11:13:39 Leela kernel: [1901306.209452] EXT4-fs error (device dm-2): htree_dirblock_to_tree:586: inode #2: block 127754: comm bash: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
Jul  7 11:13:39 Leela kernel: [1901306.216758] EXT4-fs error (device dm-2): htree_dirblock_to_tree:586: inode #2: block 127754: comm bash: bad entry in directory: rec_len is smaller than minimal - offset=0(0), inode=0, rec_len=0, name_len=0

und Supergau, alle Dateien unterhalb von home weg.

Aushängen und Einhängen von home brachte nichts, also erstmal trotz Backups Puls auf 180. Wer braucht das schon..

Lösung brachte allerdings ein nachträgliches

Code: Alles auswählen

fsck.ext4 -y /dev/mapper/Leela-home

Damit wurden die fehlenden Extents nachgebessert. Die Dateien sind nach dem erneuten Einhängen, soweit ich das überblicken kann wieder alle da.

Also Vorsicht!

[cosmac]

Supergau, alle Dateien unterhalb von home weg.

mit welchem Kernel hast du das probiert? Zu Zeiten des Standard-Squeeze-Kernels 2.6.32 war ext4 ja noch relativ neu.

[Saxman]

mit welchem Kernel hast du das probiert? Zu Zeiten des Standard-Squeeze-Kernels 2.6.32 war ext4 ja noch relativ neu.

Code: Alles auswählen

# uname -r
2.6.38-bpo.2-amd64

[gxyz]

... leider scheint es in der Hinsicht speziell mit 2.6.38-bpo.2-amd64 ein Problem zu geben - ich hatte mittlerweile einen Fall, in dem 'chattr +e' mit einer einzelnen Datei sofort zu Dateisystemschäden geführt hat. Das e2fsck aus squeeze hat zwar die Schäden vermeintlich behoben, trotzdem ist danach ein kaputter Directory-Eintrag wieder aufgetaucht. Erst ein e2fsck aus e2fsprogs 1.41.14 hat den Schaden behoben.

Der Trick mit dem 'chattr +e' hat bei meinen Versuchen mit dem Standard-Squeeze-Kernel ohne größere Katastrophen funktioniert (dafür scheint's da allerdings bei sehr hoher I/O-Last gelegentlich deadlocks beim unmounten von Ext4-Dateisystemen zu geben )-:

Den Reifegrad von Ext3 hat Ext4 meinem Eindruck nach noch nicht so ganz erreicht ...

[Saxman]

Erst ein e2fsck aus e2fsprogs 1.41.14 hat den Schaden behoben.[...]

Woher hattest du diese Version für Squeeze? Selber portiert oder eine ältere Wheezy Version genommen?

[gxyz]

Woher hattest du diese Version für Squeeze? Selber portiert oder eine ältere Wheezy Version genommen?

einfach von http://e2fsprogs.sourceforge.net/ 'runtergeladen und kompiliert
(wobei ich natürlich nicht sagen wollte, dass alle anderen Versionen Mist sind - nachdem ich nach dem 1. Filesystemcheck gleich wieder in 'nen Fehler gelaufen war, schien es mir einfach eine gute Idee, 'mal die neueste Version zu versuchen)