Debian Etch & XFS -> Filesystem Corruption

[wirtsi]

Hello

nachdem ich mittlerweile seit ca. 6 Jahren verschiedene Rootserver habe, kann ich mir meistens selber ganz gut helfen (auch dank dieses Forums :) ), aber diesmal beisst es wirklich aus, vielleicht hat einer von den Gurus eine Idee dazu:

System Debian Etch auf 1und1 Rootserver, 2.6.18-5-amd64 Kernel ... ansonsten alles Standart-Debian Pakete, 1und1 hat / als ext3 und /usr, /var und /home als xfs vorgegeben. Hab mir gedacht, die werden schon wissen warum, angeblich ist die Performance ja besser als ext3 ... anyway.

Server läuft seit 1 1/2 Jahren ohne Mucken ... Freitag wollte ich mit aptitude Updates einspielen, plötzlich schreibt er mir, er kann in /usr nicht schreiben.

Dmesg sagt:

Code: Select all

 kernel: 0x0: 00 00 00 00 01 40 03 4e 1d 42 49 4f 5f 66 5f 62
 kernel: Filesystem "md5": XFS internal error xfs_da_do_buf(2) at line 2084 of file fs/xfs/xfs_da_btree.c.  Caller 0xffffffff8821f59

 kernel:
 kernel: Call Trace:
 kernel:  [<ffffffff8822a2f0>] :xfs:xfs_corruption_error+0xe4/0xf6
 kernel:  [<ffffffff8824d3ba>] :xfs:kmem_zone_alloc+0x56/0xa3
 kernel:  [<ffffffff8821f46d>] :xfs:xfs_da_do_buf+0x53c/0x61e
 kernel:  [<ffffffff8821f59e>] :xfs:xfs_da_read_buf+0x16/0x1b
 kernel:  [<ffffffff8821f59e>] :xfs:xfs_da_read_buf+0x16/0x1b
 kernel:  [<ffffffff88227785>] :xfs:xfs_dir2_node_addname+0x5f4/0x86a
 kernel:  [<ffffffff88227785>] :xfs:xfs_dir2_node_addname+0x5f4/0x86a
 kernel:  [<ffffffff88230bea>] :xfs:xfs_iext_bno_to_ext+0xc0/0x140
 kernel:  [<ffffffff882123ab>] :xfs:xfs_bmap_last_offset+0xcd/0xdd
 kernel:  [<ffffffff882223f4>] :xfs:xfs_dir_createname+0x122/0x134
 kernel:  [<ffffffff8824d425>] :xfs:kmem_zone_zalloc+0x1e/0x2f
 kernel:  [<ffffffff8824b6f2>] :xfs:xfs_link+0x29f/0x3b1
 kernel:  [<ffffffff88253e2b>] :xfs:xfs_vn_link+0x3d/0x8c
 kernel:  [<ffffffff80220100>] __up_read+0x13/0x8a
 kernel:  [<ffffffff80220100>] __up_read+0x13/0x8a
 kernel:  [<ffffffff8822f692>] :xfs:xfs_iunlock+0x57/0x79
 kernel:  [<ffffffff882481e6>] :xfs:xfs_access+0x3d/0x46
 kernel:  [<ffffffff88253a63>] :xfs:xfs_vn_permission+0x14/0x18
 kernel:  [<ffffffff802bf58e>] vfs_link+0x138/0x18b
 kernel:  [<ffffffff802500ad>] sys_linkat+0xca/0x126
 kernel:  [<ffffffff882478e7>] :xfs:xfs_inactive_free_eofblocks+0x1c6/0x1d6
 kernel:  [<ffffffff8022ae7b>] mntput_no_expire+0x19/0x8b
 kernel:  [<ffffffff802cfe31>] compat_sys_utime+0x58/0x66
 kernel:  [<ffffffff8025ad5a>] ia32_sysret+0x0/0xa
 kernel:
 kernel: Filesystem "md5": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c.  Caller 0xffffffff88241a35
 kernel:
 kernel: Call Trace:
 kernel:  [<ffffffff88242d30>] :xfs:xfs_trans_cancel+0x5b/0xfe
 kernel:  [<ffffffff88241a35>] :xfs:xfs_rename+0xa13/0xa9a
 kernel:  [<ffffffff88253a0c>] :xfs:xfs_vn_rename+0x2c/0x6f
 kernel:  [<ffffffff80220100>] __up_read+0x13/0x8a
 kernel:  [<ffffffff8822f692>] :xfs:xfs_iunlock+0x57/0x79
 kernel:  [<ffffffff882481e6>] :xfs:xfs_access+0x3d/0x46
 kernel:  [<ffffffff88253a63>] :xfs:xfs_vn_permission+0x14/0x18
 kernel:  [<ffffffff8020cc7d>] permission+0x87/0xce
 kernel:  [<ffffffff80228cb9>] vfs_rename+0x2d5/0x426
 kernel:  [<ffffffff80234502>] sys_renameat+0x180/0x1f9
 kernel:  [<ffffffff8020c5d8>] bit_waitqueue+0x38/0x9b
 kernel:  [<ffffffff80272f04>] sys32_lstat64+0x20/0x29
 kernel:  [<ffffffff8025ad5a>] ia32_sysret+0x0/0xa
 kernel:
 kernel: xfs_force_shutdown(md5,0x8) called from line 1139 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffff88242d4e
 kernel: Filesystem "md5": Corruption of in-memory data detected.  Shutting down filesystem: md5
 kernel: Please umount the filesystem, and rectify the problem(s)

Oha, das klingt böse ... hab ins Rescuesystem gebootet, md6 und md7 war clean, aber beim Ausführen von xfs_rescue auf md5 hat sich das System sofort aufgehängt. Argh ... da das Rescue Image noch Sarge ist, scheint da eine alte Version der xfs Tools draufzusein, die nicht mit großen Redologs klarkommt ... so hab ich mir das aus irgendwelchen Foren zusammengelesen, weiß aber nicht, ob es stimmt.

Hab den Server dann normal hochgefahren (ging zum Glück noch) und per serieller Konsole in Runlevel 1 gefahren und dort dann xfs_rescue auf md5 ausgeführt. Ziemlich böse beschädigt, hat ca. 2000 orphaned Files in lost+found erstellt, mein Glück war nur, dass das eigentlich nur unter /usr/share/doc war ... alles nicht so wichtig.

Ok, mein erster Ansatz war defekter Speicher, jetzt läuft aber schon seit mehreren Stunden gzip auf große Dateien ohne Probleme ... das scheints nicht zu sein. Festplatten wohl auch nicht, da die Raids alle immer ohne Probleme clean hochgekommen sind.

Kann es wirklich sein, dass es in xfs noch so böse Bugs gibt, die einem das Filesystem zersemmeln können? Ich meine, ein Fehler im Dateisystem darf in einem Produktivsystem wirklich nicht auftreten, das ist sozusagen der absolute Super-Gau!

Fällt jemand dazu was ein? Ähnlichen Ärger mit xfs gehabt?

Liebe Grüße

Wirtsi

[Joe User]

Oha, das klingt böse ... hab ins Rescuesystem gebootet, md6 und md7 war clean, aber beim Ausführen von xfs_rescue auf md5 hat sich das System sofort aufgehängt. Argh ... da das Rescue Image noch Sarge ist, scheint da eine alte Version der xfs Tools draufzusein, die nicht mit großen Redologs klarkommt ... so hab ich mir das aus irgendwelchen Foren zusammengelesen, weiß aber nicht, ob es stimmt.

Die xfsprogs aus Sarge sind definitiv zu alt und fehlerhaft. Auch Dein Kernel ist in Sachen XFS etwas angestaubt, an xfs_do_do_buf wurde IIRC seit 2.6.18 zwei/drei mal gearbeitet, eventuell ja auch an Deinem Problem.

Kann es wirklich sein, dass es in xfs noch so böse Bugs gibt, die einem das Filesystem zersemmeln können? Ich meine, ein Fehler im Dateisystem darf in einem Produktivsystem wirklich nicht auftreten, das ist sozusagen der absolute Super-Gau!

Bugs gibt es in allen Filesystemen und können durchaus zu vollständigem Datenverlust führen. Dagegen sind ein paar Files in lost+found harmlos.

Fällt jemand dazu was ein? Ähnlichen Ärger mit xfs gehabt?

Ich hatte bisher nur mit Reiser3 und Ext3 ähnliche Probleme, mit XFS noch nie. Ich setze XFS seit mehreren Jahren sowohl auf meinen Servern, als auch auf meinem Desktop und meinem Notebook produktiv ein. Allerdings reformatiere meine Systeme mindestens ein/zwei mal im Jahr mit den jeweils aktuellen xfsprogs.
Sei froh, dass es bei Dir nicht so http://www.rootforum.org/forum/viewtopic.php?t=44108 endete ;)
BTW: Seitdem ich hier im Forum mitlese, sind dies die beiden einzigen Threads die sich überhaupt mit kaputtem XFS beschäftigen, vergleiche das mal mit Ext3...

[wirtsi]

Hello ...

erstmal vielen Dank für deine Ratschläge ... muß ich dann auch noch meinen Senf loswerden :)

Die xfsprogs aus Sarge sind definitiv zu alt und fehlerhaft. Auch Dein Kernel ist in Sachen XFS etwas angestaubt, an xfs_do_do_buf wurde IIRC seit 2.6.18 zwei/drei mal gearbeitet, eventuell ja auch an Deinem Problem.

Naja, gut das ist halt Debian .... kennt man ja, immer etwas der Zeit hinterher, aber dafür sehr stabil. Hab nun auch ein paar Server unter Ubuntu TLS laufen, die sind da aktueller ... mal sehen ob die Dinger auch 3 Release-Upgrades ohne Neuinstallation mitmachen (was bei Debian ohne Probleme geht).

Nachdem ich, gerade auch wegen des guten Paketmanagements, auf selber kompilierte Pakete und Kernel verzichten will, kommt für mich das Einspielen neuer Dateisystem-Tools nicht in Frage.

Wenn Xfs im Standart-Kernel derart buggy ist, dann ist dieses Filesystem für mein Verständnis von Server-Verwaltung erstmal gestorben.

Dein Argument, es befinden sich viel mehr Leute mit ext2/3 Problemen im Forum finde ich auch nicht ganz schlüssig, dieses Filesystem ist halt Default in mindestens Debian und Suse, es wird daher auch weit häufiger eingesetzt als Xfs. Oft sind solche Fehler auch durch z.B. fsck auf gemountete Devices entstanden, was ich hier hatte war IMHO eine Corruption ohne "Fremdverschulden".

Ist aber doch immer wieder toll, was sich so Server einfallen lassen, um einen aus heiterem Himmel mal wieder einen halben Tag zu klauen :twisted:

Liebe Grüße

wirtsi

[daemotron]

dieses Filesystem ist halt Default in mindestens Debian und Suse

SUSE schlägt AFAIR seit 9.x standardmäßig XFS als Default vor (zumindest für alle größeren Partitionen)... Die meisten Provider-Images nutzen ebenfalls XFS (zumindest bei den beiden größten deutschen Anbietern). Von daher genießt es eigentlich schon eine recht große Verbreitung...

Ist aber doch immer wieder toll, was sich so Server einfallen lassen, um einen aus heiterem Himmel mal wieder einen halben Tag zu klauen :twisted:

Tja, sonst wär's ja langweilig

Sei froh, dass es bei Dir nicht so http://www.rootforum.org/forum/viewtopic.php?t=44108 endete

Erinner mich bloß nicht daran - mein ganzer Weihnachtsurlaub war im Eimer ](*,)

[captaincrunch]

SUSE schlägt AFAIR seit 9.x standardmäßig XFS als Default vor

Hatten die's nicht viel eher mit Reiser 'ich krieg deine Daten schon kaputt'-FS? ;)

[Joe User]

ReiserFS wurde kurz nach Hans' Verhaftung endlich als Default-FS in SUSE abgeschafft ;)

[captaincrunch]

Die war aber weit nach SuSE 9.x. ;)

[flo]

Reise hab ich auch als supporter-freundliches System kennengelernt - alle halbe Jahre ein Anruf "Server läuft nicht mehr" - draufgesehen, Daten im A...imer ... das war noch mit meinen letzten SuSE-Kisten, müsste 9.x gewesen sein. Im Nachhinein hat sich rausgestellt, daß "Kunde" den DSL-Router abends ausgeschalten hat - nach durchschnittlich 100x ausschalten war es dann wieder soweit, daß das System neu draufmusste.

[daemotron]

Nicht umsonst wurde es auch "RasierFS" genannt :D