Dateisystem-Inkonsistenzen / LVM auf Software-RAID1

[aldee]

Hallo,

auf meiner Kiste treten mindestens nach jedem Reboot (nein, kein Hard-Reset ;-) Dateisysteminkonsistenzen (ext3) auf: Beispiel:

Code: Select all

xena:~# fsck.ext3 -fy /dev/lg0/var
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Inode 540819 is in use, but has dtime set.  Fix? yes

Inode 540832 is in use, but has dtime set.  Fix? yes

Pass 2: Checking directory structure
Entry 'screen.list' in /lib/dpkg/info (458760) has deleted/unused inode 459703.         Clear? yes

Entry 'screen.postrm' in /lib/dpkg/info (458760) has deleted/unused inode 459685       .  Clear? yes

Entry 'screen.conffiles' in /lib/dpkg/info (458760) has deleted/unused inode 459       688.  Clear? yes

Entry 'screen.md5sums' in /lib/dpkg/info (458760) has deleted/unused inode 45969       4.  Clear? yes

Entry 'status' in /lib/dpkg (458757) has deleted/unused inode 459664.  Clear? ye       s

Entry 'templates.dat-old' in /cache/debconf (540673) has deleted/unused inode 37       19175.  Clear? yes

Pass 3: Checking directory connectivity
'..' in /tmp/vi.recover (2326530) is /lost+found (11), should be /tmp (2326529).
Fix? yes

Pass 4: Checking reference counts
Inode 65537 ref count is 2, should be 1.  Fix? yes

Inode 458923 ref count is 1, should be 2.  Fix? yes

Unattached inode 459489
Connect to /lost+found? yes

Inode 459489 ref count is 2, should be 1.  Fix? yes

Unattached inode 459495
Connect to /lost+found? yes

Inode 459495 ref count is 2, should be 1.  Fix? yes

Unattached inode 459503
Connect to /lost+found? yes

Inode 459503 ref count is 2, should be 1.  Fix? yes

Unattached inode 459523
Connect to /lost+found? yes

Inode 459523 ref count is 2, should be 1.  Fix? yes

Unattached inode 459666
Connect to /lost+found? yes

Inode 459666 ref count is 2, should be 1.  Fix? yes

Unattached inode 459686
Connect to /lost+found? yes

Inode 459686 ref count is 2, should be 1.  Fix? yes

Unattached inode 459692
Connect to /lost+found? yes

Inode 459692 ref count is 2, should be 1.  Fix? yes

Unattached zero-length inode 540819.  Clear? yes

Unattached zero-length inode 540832.  Clear? yes

Unattached inode 3719172
Connect to /lost+found? yes

Inode 3719172 ref count is 2, should be 1.  Fix? yes

Pass 5: Checking group summary information
Block bitmap differences:  +1337 +4960 +4983 +6692 +6783 +6787 +6867 +6869 +6988        +6992 +6996 +7008 -9043 -(9151--9153) -(9155--9162) -927778 -927811 -(931898--9       31955) -(938549--938551) -1102067 +(1150200--1150202) -(1150216--1150238) +(1178       522--1178529) -6934529 +(6936576--6936631) +6942720
Fix? yes

Free blocks count wrong for group #0 (24395, counted=24044).
Fix? yes

Free blocks count wrong for group #3 (32258, counted=32251).
Fix? yes

Free blocks count wrong for group #5 (32261, counted=32251).
Fix? yes

Free blocks count wrong for group #6 (32264, counted=32254).
Fix? yes

Free blocks count wrong for group #24 (32356, counted=32254).
Fix? yes

Free blocks count wrong for group #28 (26166, counted=26099).
Fix? yes

Free blocks count wrong for group #33 (1, counted=102).
Fix? yes

Free blocks count wrong for group #35 (1483, counted=1484).
Fix? yes

Free blocks count wrong for group #36 (836, counted=1155).
Fix? yes

Free blocks count wrong (5350118, counted=5349992).
Fix? yes

Inode bitmap differences:  -459024 -459685 -459688 -459694 -459703 -459717 +5408       49 -540853 +3457038
Fix? yes

Free inodes count wrong for group #28 (15426, counted=15416).
Fix? yes

Free inodes count wrong (3920010, counted=3920000).
Fix? yes


/dev/lg0/var: ***** FILE SYSTEM WAS MODIFIED *****
/dev/lg0/var: 12160/3932160 files (1.4% non-contiguous), 2514328/7864320 blocks

Der Status der Devices ist aber "clean", sprich, fsck rennt nicht "freiwillig" sondern muss mit -f überredet werden.

Sporadisch treten auch Input/output-Errors auf (etwa bei einem find /). Es handelt sich hier um Logical Volumes auf einem Software-RAID1. Der Hoster (H******) behauptete auf Nachfrage, einen RAM- und Plattentest durchgeführt und keine Fehler festgestellt zu haben. Das Problem trat bis vor einer Woche nicht auf, Änderungen an der Kernel-Konfiguration oder sonstige "tiefergehenden" Systemeingriffe ich nicht durchgeführt; ein Kernel-Update (von 2.6.19.2-grsec auf 2.6.19.3-grsec) bin ich nach Auftreten des Problems auch einmal gefahren, geändert hat sich nichts.

/proc/mdstat sieht soweit ok aus.

Hat jemand einen Tip für mich, ob bzw. wo es am ehesten Sinn machen würde, mit einer weiteren Suche zu beginnen? Das RAM scheint in Ordnung zu sein, zumindest lief der stress test von mprime gestern einige Stunden lang ohne Fehler. Hat evtl. jemand einen Tip für einen "hard disk stress test"? ;-)

[captaincrunch]

Welche Distri und welcher Kernel sind dabei im Einsatz?

[aldee]

Kernel-Version hatte ich schon genannt (derzeit 2.6.19.3-grsec (spender), davor 2.6.19.2-grsec, mit beiden dasselbe). Meinst du, es wäre sinnvoll, die ganze .config zu posten? Distribution ist Debian Etch. Evtl. zu erwähnende Besonderheit ist, dass auf meinen Logical Volumes ein "autonomes" Debian Sarge läuft, das unterhalb das Debian Etch-"Basissystem" gechrooted ist. Das Debian außerhalb des chroots hatte ich IIRC Anfang des Jahres von Sarge auf Etch umgestellt, ansonsten habe ich außer regelmäßigen apt-get upgrades seitdem nichts außergewöhnliches geändert. Einen 2.6.19.2er Kernel hatte ich auch bereits seit kurz nach Erscheinen laufen.

[aldee]

Keiner mehr eine Idee? Mir würde schon eine "deppensichere" Methode reichen, einen möglichen Hardwaredefekt zweifelsfrei festzustellen.

[mcclane]

Hi,

ich hab ein ähnliches Problem auf einem Standard Debian Sarge mit dem 2.6er Kernel, LVM2 und Software Raid1.
Nach dem Update vom 2.4er auf den 2.6er war eine der Partition vom Raid1 offline und ließ sich auch nicht wieder hinzufügen.
Nach dem ich testweise manuell die andere Raid Partition als faulty markiert habe ließ sich auch die nicht mehr wieder reaktivieren.
Ich bin dann wieder zurück auf den 2.4er Kernel.
Dort waren beide wieder aktiv und synchronisierten.

Ich habe das in einer VM nachgestellt, dort lief es aber ohne Probleme.
Einziger Unterschied zwischen dem realen System und der VM war das ich das reale System über den Debian Installer schon bei der Installation mit Raid und LVM eingerichtet habe. Die VM habe ich von Hand nachträglich auf Raid und LVM gebracht.

[mcclane]

Ich habe ein identisches System mal in einer VM nachgebaut. Auch dort lief es.
Der einzige Unterschied zu der realen Maschine: Die hat SATA Platten drin. Und diese heißen beim 2.4er Kernel hde und hdg und beim 2.6er dann sda und sdb.
Aber abgesehen davon waren die Systeme identisch.

[Joe User]

Eventuell ein Bug in Debians e2fsprogs? Welche Version und welche Patche verwendet Debian? Treten die "Fehler" auf einem mit den aktuellen e2fsprogs (vanilla) angelegtem EXT3 ebenfalls auf? Und was sagt das aktuelle e2fsck (vanilla) zum alten EXT3?

[mcclane]

Also ich habe auf allen Systemen XFS im Einsatz (ausser auf /boot, da ists EXT2)

[daemotron]

Welche LVM2-Module habt Ihr denn aktiv? Einige von denen sind als experimental gekennzeichnet...

[mcclane]

Code: Select all

dm-crypt.ko   
dm-snapshot.ko 
md.ko       
raid1.ko
dm-mod.ko 

Das sind die, die ich brauche. Ist der Debian Standardkernel 2.6.8-3.

[Joe User]

Also ich habe auf allen Systemen XFS im Einsatz (ausser auf /boot, da ists EXT2)

Demnach prüfst Du per e2fsck ein XFS, oder wie ist Folgendes zu deuten?

Code: Select all

xena:~# fsck.ext3 -fy /dev/lg0/var

[mcclane]

Nee, das ist vom OP.
Mein Fehler ist, dass das ich ein Raid verliere wenn ich mit dem 2.6er Kernel boote. Und ich kann es auhch nicht wieder in Betrieb nehmen. Nur wenn ich wieder mit dem 2.4er boote.

[Joe User]

Nee, das ist vom OP.

Oops, sorry :roll: