zerstörtes Filesystem und Typ der Festplatte

[heinz158]

hallo,
ich möchte hier ein Umfrage zu dem schon mehrfach beschriebenen Problem "zerstörtes Filesystem" und "Typ der Festplatte" starten. Die gleiche Umfrage habe ich auch im dbox2 / Linux Forum gepostet, bitte nur einmal antworten!
Hintergrund: Meine erste Festplatte in der dbox, eine ältere 20GB Seagate ST320423A, funktionierte vom ersten Moment an einwandfrei. Ich hatte sie 3 Monate lang in Betrieb ohne ein einziges Problem. Vor zwei Wochen habe ich eine neue 200 GB Platte Samsung HA200JC eingebaut. Seitdem gibt es immer wieder Probleme mit zerstörtem Filesystem. Auch wenn die Box sauber heruntergefahren wurde, läßt sich dann beim Starten der Box das Filesystem nicht mounten, so dass ein xfs_repair nötig wird. dmesg enthält Einträge wie:
<4>XFS: bad magic number
<4>XFS: SB validate failed
oder
<5>Starting XFS recovery on filesystem: ide0(3,2) (dev: ide0(3,2))
<1>Filesystem "ide0(3,2)": xfs_inode_recover: Bad inode magic number, dino ptr = 0xc1429000, dino bp = 0xc179b490, ino = 128
<1>Filesystem "ide0(3,2)": XFS internal error xlog_recover_do_inode_trans(1) at line 2366 of file xfs_log_recover.c. Caller 0xc3c6260c
<4>XFS: log mount/recovery failed: error 990
oder
<5>Starting XFS recovery on filesystem: ide0(3,2) (dev: ide0(3,2))
<4>XFS: failed to read root inode
Im dbox2 / Linux Forum habe ich gelesen, dass auch andere dieses Problem haben, auch mit ext2 und ext3. Es liegt also nicht am Filesystem. Ein Problem war, dass die Platte, wenn vor dem Herunterfahren im Standby-Modus, so dass während Herunterfahren erst aufgeweckt, nach dem Herunterfahren nicht ausgeschaltet wurde und weiter lief. Das ließ sich beseitigen durch rechtzeitiges Wecken der Platte vor dem Herunterfahren in der start_neutrino mit einem "ls /hdd >/dev/null; sleep 10" direkt nach "/bin/neutrino -u -f".
Andere User haben spezielle Massnahmen entwickelt, um das Filesystem Problem zu vermeiden, wie amigaherbie http://tuxbox-forum.dreambox-fan.de/for ... start=1659
mit write cache aus, swap an/aus und Verzicht auf standby mode. Auch mit write cache aus und sauberem Herunterfahren hatte ich jetzt dennoch wieder ein zerstörtes XFS und diesmal die Hälfte meiner Dateien unwiederbringlich verloren. Damit ist der Spass vorbei. Die bisher genannten Massnahmen funktionieren nicht wirklich sicher. Und sind prinzipiell auch nicht nötig, da offenbar die meisten User hier keine solche Probleme haben, und ich mit der ersten Festplatte auch nicht hatte.
Ich möchte nun feststellen, ob sich das Thema bestimmten Festplatten zuordnen läßt und bitte euch um Antwort, und zwar entweder:

"noch nie ein Filesystem-Problem gehabt: Festplattentyp, Filesystem, Image, dbox"

oder:

"kenne geschildertes Filesystem-Problem: Festplattentyp, Filesystem, Image, dbox"

Ich mache hier gleich den Anfang:

noch nie ein Filesystem-Problem gehabt: Seagate ST320423A 20GB 5.400rpm 512KB Cache, xfs, JTG 2.2.2, Nokia Kabel Avia600

kenne geschildertes Filesystem-Problem: Samsung HA200JC 200GB 5.760rpm 2MB Cache, xfs, JTG 2.2.2, Nokia Kabel Avia600

Bitte um zahlreiche Antworten ...
Beste Grüße
Heinz

[heinz158]

hallo, ich habe hier zur Info mein Bootlog angehängt. Wie gesagt, umount beim Shutdown ist ok.
Das Problem hängt offenbar von der verwendeten Festplatte ab, und darum geht es mir.

PS: könnt ihr bitte noch angeben, ob bei eurer Festplatte die Smart Features aktiviert sind (Skript HDD-Info / Smartstatus SMART support is: Enabled)?

Danke und Gruß
Heinz

[*swordfish]

OK Heinz bitte sehr:

noch nie ein Filesystem-Problem gehabt: Samsung SpinPoint V120CE HA250JC 5.760rpm 2MB Cache, xfs, JTG 2.2.2, neuestes Snap, S.M.A.R.T enabled, SAGEM 1x Kabel Avia600

[CastorRanger]

hallo heinz,
hab heute auch das von Dir beschriebene Problem und lasse gerade XFS_Repair durch laufen - dauert aber ganz schön lange.

Sobald meine Platte wieder läuft reiche ich die Infos nach, welche Plattengröße etc.
Mein Bootlog

Box: Sagem, 1 x Intel Flash, AVIA600, Kabel, IDE IF, HDD....

Tschaui

[DrRamoray]

Festplatten siehe Signatur, Filesystem ext3

[saruman]

Also ein Filesystemcheck mit anschließendem Nachfahren des Journals ist nur beim Status *UNCLEAN* des Filesystems nötig. Das passiert, wenn das FS nicht sauber abgemountet wurde. Soweit sind wir sicher d'accord.

Ein umount eines XFS kann in der Regel recht lange dauern, je nach Größe des Filesystems. Wäre es nicht möglich, dass die Box beim Runterfahren schon ausschaltet, obwohl das umount noch nicht terminiert hat?

Gegenfrage: Was passiert denn, wenn Ihr im laufenden Betrieb im Terminal mal das FS abmountet und danach wieder anmountet? Braucht das Filesystem dann auch einen FSCK?

[palace]

XFS verhält sich nicht wie ext2/3 und xfs_repair leider auch nicht wie fsck.

Ansonsten bin ich Deiner Meinung, dass die Box ausgeht, bevor zuende geschrieben wurde (ggf auch der HDD Cache)

Ein etwas grosszügigeres Sleep nach dem umount sollte hier Abhilfe schaffen; leider gelingt auch ein umount nicht immer, weil hier noch irgendwas einen Handle drauf hat.

Möglicherweise kann man hier bei Linux Distributionen abgucken.

[saruman]

Wenn noch offene Filehandles bestehen sollte man schauen, ob man mal fuser oder lsof für die dbox übersetzt bekommt und schauen, was das FS busy hält.

Ich selber hab kein Interface, ansonsten hätt ich hier schon mal angesetzt...

[Gorthol]

kenne geschildertes Filesystem-Problem: Samsung SP1604N 160GB 7200rpm 2MB Cache, xfs, JTG 2.2.2 (Snapshot vom 26.02.2007), Nokia Sat Avia500

Edit:
Mit dem Workaround "ls /hdd >/dev/null; sleep 10" in der start_neutrino bisher kein Problem mehr.