Nachdem ich dieses Problem gelöst wähnte, habe ich jetzt ein Neues, wobei ich nicht mit Sicherheit sagen könnte, ob das Problem vorher schon da war oder nicht. Jedenfalls habe ich beim Rumprobieren bzgl. Hibernation festgestellt, dass wenn die Platten eingeschlafen sind, sie ca. 1 Minute zum Aufwachen brauchen, was mir sehr lang erschien. Ein Blick in /var/log/messages fördert zutage, dass jedes Mal, wenn die Platten aufgeweckt werden, Folgendes passiert:
Da die zweite Platte diejenige ist, die das Problem in dem oben verlinkten Thread hatte, vermute ich mal, dass es auch hier um die zweite Platte geht, d.h. der erste Eintrag um 14:33:53 bedeutet, dass die erste Platte erfolgreich hochgefahren wurde, und alles, was danach kommt, bezieht sich auf die zweite Platte, die dann letztlich aber auch erfolgreich hochfährt. Ist das zutreffend?
Von diesem Problem abgesehen funktioniert alles reibungslos, aber wie in dem oben verlinkten Thread auch schon gesagt, traue ich dem Ganzen nun natürlich erst recht nicht mehr über den Weg. Was ich nach wie vor für ausgeschlossen halte, ist, dass die Platte einen physischen Defekt hat, denn sowohl der erweiterte SMART-Test in der DS als auch ein kompletter Oberflächentest am PC mit dem Diagnosetool von WD brachten keinen Fehler zutage. Auch die SMART-Werte der Platte sind völlig normal und nahezu identisch mit denen der anderen Platte.
Andererseits kann ich mir aber auch kein Kompatibilitätsproblem vorstellen, denn ich habe ja 2x exakt dieselbe Platte (selbe Firmware, selbe Batchnummer), und die andere hat kein Problem.
Kann sich da jemand einen Reim drauf machen?
Code:
Feb 5 14:33:53 scemd: SCEMD: disk 1 wake up from hibernation
Feb 5 14:35:01 kernel: [ 3411.081148] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
Feb 5 14:35:01 kernel: [ 3411.088533] ata1.00: failed command: WRITE FPDMA QUEUED
Feb 5 14:35:01 kernel: [ 3411.094021] ata1.00: cmd 61/08:00:80:ff:4b/00:00:00:00:00/40 tag 0 ncq 4096 out
Feb 5 14:35:01 kernel: [ 3411.094024] res 40/00:00:00:fb:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Feb 5 14:35:01 kernel: [ 3411.109474] ata1.00: status: { DRDY }
Feb 5 14:35:02 kernel: [ 3411.444597] ata1.00: device reported invalid CHS sector 0
Feb 5 14:35:08 kernel: [ 3418.116998] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
Feb 5 14:35:08 kernel: [ 3418.124342] ata2.00: failed command: WRITE FPDMA QUEUED
Feb 5 14:35:08 kernel: [ 3418.129805] ata2.00: cmd 61/08:00:80:ff:4b/00:00:00:00:00/40 tag 0 ncq 4096 out
Feb 5 14:35:09 kernel: [ 3418.129808] res 40/00:00:00:fb:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Feb 5 14:35:09 kernel: [ 3418.145329] ata2.00: status: { DRDY }
Feb 5 14:35:09 kernel: [ 3418.480784] ata2.00: device reported invalid CHS sector 0
Feb 5 14:35:09 scemd: SCEMD: disk 2 wake up from hibernationDa die zweite Platte diejenige ist, die das Problem in dem oben verlinkten Thread hatte, vermute ich mal, dass es auch hier um die zweite Platte geht, d.h. der erste Eintrag um 14:33:53 bedeutet, dass die erste Platte erfolgreich hochgefahren wurde, und alles, was danach kommt, bezieht sich auf die zweite Platte, die dann letztlich aber auch erfolgreich hochfährt. Ist das zutreffend?
Von diesem Problem abgesehen funktioniert alles reibungslos, aber wie in dem oben verlinkten Thread auch schon gesagt, traue ich dem Ganzen nun natürlich erst recht nicht mehr über den Weg. Was ich nach wie vor für ausgeschlossen halte, ist, dass die Platte einen physischen Defekt hat, denn sowohl der erweiterte SMART-Test in der DS als auch ein kompletter Oberflächentest am PC mit dem Diagnosetool von WD brachten keinen Fehler zutage. Auch die SMART-Werte der Platte sind völlig normal und nahezu identisch mit denen der anderen Platte.
Andererseits kann ich mir aber auch kein Kompatibilitätsproblem vorstellen, denn ich habe ja 2x exakt dieselbe Platte (selbe Firmware, selbe Batchnummer), und die andere hat kein Problem.
Kann sich da jemand einen Reim drauf machen?
