Hallo zusammen,
vor ca. einem Jahr habe ich mir einen neuen Server gebaut, da mein vorheriger mit SuSE 7.0 so langsam in Rente gehen wollte.
Zuerst habe ich ihn als Fileserver eingerichtet, sowohl via Samba, als auch via NFS. Alles lief sehr schön, bis ich mit meiner alten D-Box Aufnahmen via NFS auf den Server sendete.
Durch das RAID-5 (Soft-Raid mit 5 Platten à 1TB) merkte ich noch nicht gleich, dass bereits die erste Platte ausfiel. Da der Server noch im Aufbau war, wurde ich auch nicht davon informiert. Das hatte zur Folge, das die nächste Platte ausfiel und alles zusammenbrach.
Gut, dadurch erlangte ich das Wissen, wie man kaputte Soft-Raids wieder zusammenbastelt, aber es hat ein ungutes Gefühl hinterlassen.
Es hat auch ein wenig gedauert, bis ich es begriffen und realisiert habe, dass es die D-Box Aufnahme via NFS war, die die Platten ausfallen lies. Zuerst hatte ich S.M.A.R.T. im Verdacht, dann eine zu hohe Festplatten-Temperatur, und manch andres mehr.
Erst, als mir das wiederholt passierte, stellte ich den Zusammenhang fest. Ja, ich konnte das auch nicht glauben, sendet die D-Box doch auch nur mit 10MBit. Von anderen Rechnern wenn ich via SAMBA mehrfach mit 100MBit Daten sende gibt es keinerlei Probleme. Die erste 1/2 Stunde ~ Stunde geht i.d.R. auch alles gut, dann kommt der Ausfall einer Platte.
Nach weiteren Studien stelle ich fest: Als ich einst das RAID baute, hatte ich noch eine 1TB Platte, eine ST31000528AS. Dazu kaufte mich mir vier ST1000DL002-9TT153. Die alte Platte ist, nach inzwischen 12 Ausfällen noch nie ausgefallen. Ein Problem also mit der Baureihe der neuen Platten, denke ich. Aber auf der Seagate-Website gibt es für diese Platte keine neue Firmware.
UND: Seltsam, dass nur NFS den Ausfall bewirkt, nicht SAMBA oder direkter lokaler Zugriff???
Ein Ausfall schaut im log z.B. so aus:
Oct 29 20:08:58 goofy kernel: [1215980.704049] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Oct 29 20:08:58 goofy kernel: [1215980.704054] ata6.00: failed command: IDENTIFY DEVICE
Oct 29 20:08:58 goofy kernel: [1215980.704060] ata6.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
Oct 29 20:08:58 goofy kernel: [1215980.704061] res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
Oct 29 20:08:58 goofy kernel: [1215980.704064] ata6.00: status: { DRDY }
Oct 29 20:08:58 goofy kernel: [1215980.704070] ata6: hard resetting link
Oct 29 20:09:01 goofy /USR/SBIN/CRON[4245]: (root) CMD (/usr/sbin/monitorix.pl update)
Oct 29 20:09:03 goofy kernel: [1215986.209029] ata6: link is slow to respond, please be patient (ready=0)
Oct 29 20:09:08 goofy kernel: [1215990.748070] ata6: SRST failed (errno=-16)
Oct 29 20:09:08 goofy kernel: [1215990.748077] ata6: hard resetting link
Oct 29 20:09:14 goofy kernel: [1215996.253023] ata6: link is slow to respond, please be patient (ready=0)
Oct 29 20:09:18 goofy kernel: [1216000.792029] ata6: SRST failed (errno=-16)
Oct 29 20:09:18 goofy kernel: [1216000.792036] ata6: hard resetting link
Oct 29 20:09:24 goofy kernel: [1216006.297028] ata6: link is slow to respond, please be patient (ready=0)
Oct 29 20:09:53 goofy kernel: [1216035.826031] ata6: SRST failed (errno=-16)
Oct 29 20:09:53 goofy kernel: [1216035.826036] ata6: limiting SATA link speed to 1.5 Gbps
Oct 29 20:09:53 goofy kernel: [1216035.826042] ata6: hard resetting link
Oct 29 20:09:58 goofy kernel: [1216040.872032] ata6: SRST failed (errno=-16)
Oct 29 20:09:58 goofy kernel: [1216040.872035] ata6: reset failed, giving up
Oct 29 20:09:58 goofy kernel: [1216040.872038] ata6.00: disabled
Oct 29 20:09:58 goofy kernel: [1216040.872057] ata6: EH complete
Oct 29 20:09:58 goofy kernel: [1216040.872083] sd 5:0:0:0: [sde] Unhandled error code
Oct 29 20:09:58 goofy kernel: [1216040.872085] sd 5:0:0:0: [sde] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 29 20:09:58 goofy kernel: [1216040.872089] sd 5:0:0:0: [sde] CDB: Write(10): 2a 00 01 53 07 e8 00 00 01 00
Oct 29 20:09:58 goofy kernel: [1216040.872097] end_request: I/O error, dev sde, sector 22218728
Oct 29 20:09:58 goofy kernel: [1216040.872104] end_request: I/O error, dev sde, sector 22218728
Oct 29 20:09:58 goofy kernel: [1216040.872106] md: super_written gets error=-5, uptodate=0
Oct 29 20:09:58 goofy kernel: [1216040.872111] md/raid:md0: Disk failure on sde3, disabling device.
Oct 29 20:09:58 goofy kernel: [1216040.872112] <1>md/raid:md0: Operation continuing on 4 devices.
Oct 29 20:09:58 goofy kernel: [1216040.960789] RAID conf printout:
Oct 29 20:09:58 goofy kernel: [1216040.960792] --- level:5 rd:5 wd:4
Oct 29 20:09:58 goofy kernel: [1216040.960795] disk 0, o:1, dev:sdb3
Oct 29 20:09:58 goofy kernel: [1216040.960797] disk 1, o:1, dev:sdc3
Oct 29 20:09:58 goofy kernel: [1216040.960799] disk 2, o:1, dev:sdd3
Oct 29 20:09:58 goofy kernel: [1216040.960801] disk 3, o:0, dev:sde3
Oct 29 20:09:58 goofy kernel: [1216040.960803] disk 4, o:1, dev:sda3
Um die Platte wieder in Gang zu bekommen reicht weder Warmstart, noch Reset-Knopf: Ich muss den Rechner ausschalten, dann klappts wieder.
Irgendwie verlor ich da einst dann auch die Lust und das Vertrauen, den Server weiterzubauen und ich belies es bei dem Fileserver für SAMBA. Ja, ich habe immer wieder mal eine I-Net-Recherche gemacht, aber mein Problem war nicht auffindbar. Und dann wollte ich auch noch Gegenchecken, ob es die DBox da irgendwas spezielles macht oder jeglicher NFS-Datenverkehr nach gewisser Zeit zu Ausfall führt. Irgendwie sind so jetzt über ein Jahr vergangen. Und vor ein paar Tagen, als sich mein alter SuSE 7 Server wieder mit röchelnden Geräuschen meldete habe ich mir überlegt, vielleicht mal trotz Spiegelung die Daten als tar.gz auf den neuen Fileserver rüberzupacken. Von Linux zu Linux natürlich via NFS… das ging sogar ein paar Stunden gut, dann kam Aufall.
Inzwischen sind die Plattenpreise ja wieder etwas gesunken. Ich bin echt am Überlegen mir mal ein zwei andere Platten zu holen und zu sehen, was passiert. Aber trotzdem kann das doch alles nicht sein?
Hat jemand noch einen Tipp für mich?
Mainboard: Gigabyte P35-DS3
CPU: Intel(R) Core™2 Duo CPU
RAM: 4GB
Danke & Grüße
