Volume (SHR) abgestürzt; Hardware- oder Softwarefehler?

[seba]

Hallo,

irgendwie werde ich mit meiner DS710+ nicht glücklich.

Nach dem ein und anderem Problem ist jetzt auch noch Disk 2 (WD20EARS-00MVWB0) vom SHR abgestürzt.

Im Log steht jede Menge (gekürzt).

Jan 30 20:10:35 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:35 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:35 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy_directory.c:398 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:10:36 file_MVCP.cgi: copy_file_copy_directory.c:398 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted

Jan 30 20:17:07 kernel: [23438.487205] ata2.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen
Jan 30 20:17:07 kernel: [23438.495328] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:17:07 kernel: [23438.500784] ata2.00: cmd 61/00:00:68:dc:2e/04:00:7a:00:00/40 tag 0 ncq 524288 out
Jan 30 20:17:07 kernel: [23438.500787]          res 40/00:0c:d0:3a:1e/00:00:33:00:00/40 Emask 0x4 (timeout)
Jan 30 20:17:07 kernel: [23438.516479] ata2.00: status: { DRDY }
Jan 30 20:17:07 kernel: [23438.520225] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:17:07 kernel: [23438.525829] ata2.00: cmd 61/00:08:68:e0:2e/04:00:7a:00:00/40 tag 1 ncq 524288 out
Jan 30 20:17:07 kernel: [23438.525833]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:17:07 kernel: [23438.541554] ata2.00: status: { DRDY }
Jan 30 20:17:07 kernel: [23438.545436] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:17:07 kernel: [23438.550926] ata2.00: cmd 61/00:10:68:e4:2e/04:00:7a:00:00/40 tag 2 ncq 524288 out
Jan 30 20:17:07 kernel: [23438.550930]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:18:09 file_MVCP.cgi: copy_file_copy.c:386 failed to fchown destination to uid=1024, gid=100, errno=1/Operation not permitted
Jan 30 20:17:07 kernel: [23438.566701] ata2.00: status: { DRDY }
Jan 30 20:18:09 scemd: ScemRefreshDiskLed(528)Disk 2 fail
Jan 30 20:18:09 kernel: [23438.570564] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:18:09 kernel: [23438.576055] ata2.00: cmd 61/00:18:68:e8:2e/04:00:7a:00:00/40 tag 3 ncq 524288 out
Jan 30 20:18:09 kernel: [23438.576058]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:18:09 kernel: [23438.591787] ata2.00: status: { DRDY }
Jan 30 20:18:09 kernel: [23438.595610] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:18:09 kernel: [23438.601057] ata2.00: cmd 61/00:20:68:c4:2e/04:00:7a:00:00/40 tag 4 ncq 524288 out
Jan 30 20:18:09 kernel: [23438.601060]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:18:09 kernel: [23438.616969] ata2.00: status: { DRDY }
Jan 30 20:18:09 kernel: [23438.620866] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:18:09 kernel: [23438.626383] ata2.00: cmd 61/00:28:68:c8:2e/04:00:7a:00:00/40 tag 5 ncq 524288 out
Jan 30 20:18:09 kernel: [23438.626386]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:18:09 kernel: [23438.642253] ata2.00: status: { DRDY }
Jan 30 20:18:09 kernel: [23438.646171] ata2.00: failed command: WRITE FPDMA QUEUED
Jan 30 20:18:09 kernel: [23438.651636] ata2.00: cmd 61/00:30:68:cc:2e/04:00:7a:00:00/40 tag 6 ncq 524288 out
Jan 30 20:18:09 kernel: [23438.651639]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 20:18:09 kernel: [23438.667482] ata2.00: status: { DRDY }

Jan 30 20:18:09 kernel: [23499.619388] ata2.00: device reported invalid CHS sector 0
Jan 30 20:18:09 kernel: [23499.625075] ata2.00: device reported invalid CHS sector 0
Jan 30 20:18:09 kernel: [23499.630768] ata2.00: device reported invalid CHS sector 0
Jan 30 20:18:09 kernel: [23499.636436] ata2.00: device reported invalid CHS sector 0
Jan 30 20:18:09 kernel: [23499.664685] end_request: I/O error, dev sdb, sector 2049884264
Jan 30 20:18:09 kernel: [23499.670673] write error, md2, sdb5 index [1], sector 2049884272 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.679362] raid1: Disk failure on sdb5, disabling device.
Jan 30 20:18:09 kernel: [23499.679364]  Operation continuing on 1 devices
Jan 30 20:18:09 kernel: [23499.689784] write error, md2, sdb5 index [1], sector 2049884280 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.698384] write error, md2, sdb5 index [1], sector 2049884288 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.707048] write error, md2, sdb5 index [1], sector 2049884296 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.715733] write error, md2, sdb5 index [1], sector 2049884304 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.724357] write error, md2, sdb5 index [1], sector 2049884312 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.733013] write error, md2, sdb5 index [1], sector 2049884320 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.741751] write error, md2, sdb5 index [1], sector 2049884328 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.750289] write error, md2, sdb5 index [1], sector 2049884336 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.758919] write error, md2, sdb5 index [1], sector 2049884344 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.787273] end_request: I/O error, dev sdb, sector 2049883240

Für mich sieht es ja fast so aus, als ob die unzähligen misslungen Aufrufe (lt. Logfile mehrere hunderte Aufrufe) von fchown dem System ganz schön zugesetzt haben und es so vielleicht zum Absturz gekommen sein könnte? Was mein Ihr? Wie stabil laufen die SHR denn im Allgemeinen? Oder soll die HD tatsächlich den Geist aufgegeben haben?

Gruß

Sebastian

P.S. Zum Fehler kam es wohl, weil ich über den Web Datei Browser als eingeschränkter User einen Ordner (Besitzer admin, Gruppe users) in ein anderes Verzeichnis kopiert habe.

 

[Super-Grobi]

naja, das fchon mit Fehler zurückkommt, dürfte mehr Folge als Ursache sein.

Deine eine Platte hat einen weg

Jan 30 20:18:09 kernel: [23499.636436] ata2.00: device reported invalid CHS sector 0
Jan 30 20:18:09 kernel: [23499.664685] end_request: I/O error, dev sdb, sector 2049884264
Jan 30 20:18:09 kernel: [23499.670673] write error, md2, sdb5 index [1], sector 2049884272 [raid1_end_write_request]
Jan 30 20:18:09 kernel: [23499.679362] raid1: Disk failure on sdb5, disabling device.
Jan 30 20:18:09 kernel: [23499.679364]  Operation continuing on 1 devices
Jan 30 20:18:09 kernel: [23499.689784] write error, md2, sdb5 index [1], sector 2049884280 [raid1_end_write_request]

Grüße

 

[seba]

Hardwaredefekt kann natürlich sein....

Ich könnte mir aber durchaus vorstellen, dass es auch Treiber Probleme etc. sein könnten. Ich erinnere mich noch an meine erste Suse Installation, bei der ich mit ähnlichen Fehlern zu kämpfen hatte. Damals war es lediglich eine falsche Kernel Config.

Andere berichten auch von diesen Fehlern im Zusammenhang mit Datenlast

http://forums.gentoo.org/viewtopic-t-851269-start-0.html
Edit
http://forum.ubuntuusers.de/topic/sata-verbindung-friert-bei-last-ein/#post-2707003
http://www.unixboard.de/vb3/showthread.php?46893-Debian-5.0.6-hat-H%E4nger-bei-Datenlast

 

[Matthieu]

Dort kommt es meist bei SSDs vor, wenn ich das richtig gelesen habe. Außerdem treten die Probleme nach einem Kernel-Update auf. Der Kernel in der DS ist aber schon etwas älter und wird bei Updates meist nur gepatcht. Die Menge an Fehlern bringt mich eigentlich auf die selbe Schlussfolgerung wie Super-Grobi.

MfG Matthieu

 

[seba]

Ich hab jetzt noch einmal beide HDs mit den Tools von WD geprüft und vollständig gelöscht, danach das System neu aufgesetzt. Die HDs hab ich dabei testweise mal getauscht.

Mal sehen, ob das Volume wieder abstürzt und wenn ja, welche HD dann daran Schuld ist. Wenn es die erste ist, werd ich sie dann einschicken/tauschen.

Gruß

Sebastian

 

[jahlives]

@Seba
Mal die SMART Werte der Platten geprüft? Irgendwelche auffällige Werte?

 

[seba]

SMART Werte sind alle OK, sowohl lt. der Diskstation als auch lt. dem Tool von WD. Test auf defekte Sektoren brachte auch keine Fehler zutage.

 

[jahlives]

Du hast ja WD20EARS. Sind das nicht die Platten mit 4k Blöcken? Bei denen muss man afaik im Setup darauf achten, das "schrittweise Setup" zu wählen und nicht die automatische Version. Nur dann werden die Partitionen korrekt ausgerichtet. Oder geht das mit aktuellen Firmwaren nun auch mit auto Setup korrekt?

 

[Super-Grobi]

Moinsen

Du hast ja WD20EARS. Sind das nicht die Platten mit 4k Blöcken?

Jepp!

Bei denen muss man afaik im Setup darauf achten, das "schrittweise Setup" zu wählen und nicht die automatische Version. Nur dann werden die Partitionen korrekt ausgerichtet.

Bin mir nicht ganz sicher, aber ab DSM3.0 ist das glaube ich kein Thema mehr

Oder geht das mit aktuellen Firmwaren nun auch mit auto Setup korrekt?

Man kann das ja über telnet überprüfen, kurz "fdisk -lu" eingeben,
in der erscheinenden Tabelle sollten die Werte unter "Start" durch 8 teilbar sein, wenn ja => alles ist gut....

Grüße

 

[seba]

Gerade mal von der Ferne geguckt, ist bei beiden 256.

Gruß

Sebastian

 

[Super-Grobi]

Moin

Hat die DS Sata-Kabel, oder Backplane Lösung?
Wenn Kabel, das von der betroffenen Platte einfach mal austauschen.
Viellicht gibt es da ein Kontaktproblem in dem Steckern....

Grüße

 

[seba]

Die DS710+ hat keine Kabel. Hatte aber mal die Kontakte/Stecker mal ausgeblasen/abgepustet.