ext3-Fehler -> Dateisystem ro

[felixs]

Hallo,

einer meiner Server (CentOS 4 im 64-Bit-Mode) ist gestern abend offenbar auf einen hässlichen ext3-Fehler gestoßen: Die beiden Festplatten in einem Software-RAID 1 vereint, darauf befinden sich eine boot-Partition und ein LVM für /, /var/ und /tmp. Als Dateisystem verwende ich überall ext3.

Ansonsten keine besonderen Einstellungen, was Kernel und Dateisystem angeht.

Code: Select all

Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0): ext3_free_blocks_sb: bit already cleared for block 2318352
Apr 23 20:44:48 mail1 kernel: Aborting journal on device dm-0.
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_free_blocks_sb: Journal has aborted
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_free_blocks_sb: Journal has aborted
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_reserve_inode_write: Journal has aborted
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_reserve_inode_write: Journal has aborted
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_orphan_del: Journal has aborted
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in ext3_truncate: Journal has aborted
Apr 23 20:44:48 mail1 kernel: ext3_abort called.
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Apr 23 20:44:48 mail1 kernel: Remounting filesystem read-only
Apr 23 20:44:48 mail1 kernel: EXT3-fs error (device dm-0) in start_transaction: Journal has aborted

Im Rettungssystem habe ich dann einen fsck ausgeführt:

Code: Select all

e2fsck 1.37 (21-Mar-2005)
/dev/mapper/harddisk-system: recovering journal
/dev/mapper/harddisk-system contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes

Inode 276355 was part of the orphaned inode list.  FIXED.
Inode 276356 was part of the orphaned inode list.  FIXED.
Inode 276357 was part of the orphaned inode list.  FIXED.
Inode 1137942, i_size is 0, should be 24576.  Fix<y>? yes

Pass 2: Checking directory structure
Entry 'null' in /dev (97537) has deleted/unused inode 97543.  Clear<y>? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -585728 -(2294271--2294274) +2318352
Fix<y>? yes

Free blocks count wrong for group #17 (2, counted=3).
Fix<y>? yes

Free blocks count wrong (1640514, counted=1640515).
Fix<y>? yes

Inode bitmap differences:  -(276354--276357)
Fix<y>? yes

Free inodes count wrong for group #17 (16249, counted=16253).
Fix<y>? yes

Free inodes count wrong (1246529, counted=1246533).
Fix<y>? yes


/dev/mapper/harddisk-system: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/harddisk-system: 37691/1284224 files (1.8% non-contiguous), 923581/2564096 blocks

Anschließend bootet der Server wieder. Allerdings bereitet mir die Geschichte schon etwas Bauchschmerzen... Hat jemand schon mal ähnliche Probleme gehabt? Welche Informationen könnten noch weiterhelfen?

Vielen Dank,
Felix

[sledge0303]

Ich würde das Log zum Hoster schicken und der wird schon Maßnahmen einleiten ;)

[captaincrunch]

Verwendest du die aktuellsten Pakete? Die Kombination CentOS, SW-RAID und LVM darüber führt anscheinend bei allen möglichen Leuten zu genau diesem Phänomen. AFAIR sollte das aber eigentlich gefixt sein.

[felixs]

Verwendest du die aktuellsten Pakete? Die Kombination CentOS, SW-RAID und LVM darüber führt anscheinend bei allen möglichen Leuten zu genau diesem Phänomen. AFAIR sollte das aber eigentlich gefixt sein.

Ja, alle aktuellen Updates sind drauf. Die von mir selbst kompilierten Pakete, die CentOS-RPMs ersetzen, sind alle unkritisch in Bezug auf das Dateisystem (z.B. exim).

Hast du weitere Links mit entspr. Problembeschreibungen? Ich bin mit Google nicht darauf gestoßen.

Danke,
Felix

[felixs]

Ich würde das Log zum Hoster schicken und der wird schon Maßnahmen einleiten ;)

Du meinst also, dies ist ein Hardware-Problem? Du könntest Recht haben, wenn ich mir den Wert Hardware_ECC_Recovered in der Ausgabe von smartctl ansehe: 96055916.

Ich werde noch mal einen SMART-Check durchlaufen lassen, nachdem ich wieder die Option '-d ata' gefunden habe...

fs

[captaincrunch]

Auf einem meiner privaten Systeme hatte ich ein ähnliches Setup und ziemlich die gleichen Probleme. Auch wenn https://bugzilla.redhat.com/bugzilla/sh ... ?id=213921 sich zwar auf SAN-Umgebungen bezieht, hat die Geschichte Bugfixes hervorgebracht, die (wenigstens bei mir) halfen.

[felixs]

Nachdem die Werte von Hardware_ECC_Recovered in 1 1/2 Stunden um 20% anstiegen, habe ich die Platte tauschen lassen, was auch vom Hoster in kurzer Zeit erledigt war. Dank RAID1 gab es keinen Datenverlust :-)

Ich hoffe mal, dass das Problem damit erledigt ist. Allerdings trat es ja auch bisher nur einmal auf, so dass es schwer sein wird, dies zu verifizieren.

Vielen Dank für die Antworten.
fs