DS408: Eine Platte wacht nicht auf -> Volume1 degraded

[massaquah]

Hallo zusammen,

meine Konfiguration sieht folgendermaßen aus:

DS408 mit 3x Samsung Spinpoint F1 (1TB)
Firmware 2.1 Beta
Nacht-Abschaltung (1:00-8:00)
Festplattenstandby nach 60 min

Ich habe die DS seit gerade erst knapp 3 Wochen aber ich habe es heute schon zum zweiten mal erlebt, dass die DS morgens nach dem Start piept und mir das Volume in der Weboberfläche als degraded angezeigt wird und eine der Platten nicht initialisiert wurde.
Bisher war eine Reparatur über die Weboberfläche zwar jedesmal moeglich, dennoch kann es wohl nicht Sinn der Sache sein, dass ich dies einmal pro Woche durchführen muss.

Was habe ich nun für Moeglichkeiten? Standby und Abschaltung komplett deaktivieren fände ich nicht ideal, da ich mir die DS408 (anstatt der CS407) gerade aus dem Grund zugelegt habe, weil sie sich selbständig an- und abschalten kann.

Ich habe nun schon mehrfach im Forum gelesen, dass viele von der Firmware 2.1 zurück zur 2.0 gewechselt sind, jedoch ohne einen Grund zu nennen. Koennen meine Probleme auf den Beta-Status der Firmware zurückzuführen sein oder welche Gründe kommen sonst in Frage?

Bin für jede Hilfe dankbar.

 

[itari]

Ich nehme an, dass du die Firmware DSM 2.0-0803 (Status im DS Manager) drauf hast, oder? Und dass du einen RAID-5 gebaut hast, oder?

Hast du mal einen Smart-Test auf besagte Platte laufen lassen?

Itari

 

[massaquah]

Ja, ist beides korrekt. Firmware version ist DSM 2.0-0803 und Raid-5.

SMART Test habe ich bisher nicht laufen lassen. Von den drei eingebauten Platten hatte ich vor der DS-Zeit bereits zwei im Raid-1 laufen und habe mir dann für die DS eine zusätzliche dazu gekauft. Und komischerweise ist es bisher beide Male genau diese nagelneue Platte gewesen, die nicht initialisiert wurde.

 

[Trolli]

Man muss halt herausfinden, wo der Fehler liegt. Es gibt da halt ein paar Möglichkeiten: Festplatte, Disk Station, Kabel...

Mit einem Smarttest der Festplatte oder einem intensiven Oberflächentest am PC kann man halt schon mal die Festplatte prüfen.

Trolli

 

[massaquah]

Ich werd dann mal eben abwarten, bis der Consistency Check fertig ist und dann einen SMART Test anstarten.

Haltet ihr es für unwahrscheinlich, dass diese Probleme mit der Firmware version zu tun haben?

Vielen Dank schonmal für die sehr schnellen Antworten.

 

[Trolli]

Ja. Das halte ich in der Tat für unwahrscheinlich.

 

[itari]

Das Problem kann viele Ursachen haben, die dazu führen, dass die Platte nicht rechtzeitig aufwacht (nach deine Nachtabschaltung bzw. dem Spin-down) und daher der Inkonsistenz-Fehler auftritt: SATA-Kabel war es bei mir (DS207+), kann aber auch an der Platte liegen (andere Platten-Firmware-Version, Defekt usw.) oder am Plattencontroller (dann müsstest die DS einschicken). Es gab auch mal Firmware-Probleme, die zu einem solchen Verhalten geführt haben, das ist also auch nicht ganz auszuschließen. Eine Analyse deiner /var/log/messages wäre daher auch nicht schlecht, denn dort müsste sich ja was zu dem Fehler finden lassen.

Selbstverständlich kannst du auch mal Kontakt zum Synology-Support aufnehmen.

Itari

 

[massaquah]

Mal angenommen es liegt am SATA Port 3, wäre es möglich, die Platte statt an Port 3 einfach an Port 4 anzustöpseln (wahrscheinlich mit anschließendem Repair des Volumes)?

 

[Trolli]

Klar. Das wäre dann der nächste Schritt. Möglicherweise kann man aber im Raidsystem nicht einfach die Plattenplätze tauschen. Deshalb würde ich dann zunächst mal das Kabel austauschen. Daran könnte es halt auch liegen. Aber immer nur eine Sache gleichzeitig probieren, damit man hinterher auch wirklich weiß woran es liegt.

Trolli

 

[massaquah]

Der ausführliche SMART Test hat keinen Fehler angezeigt.

Ich hab jetzt mal den Write Cache deaktiviert. Falls (oder besser sobald) das Problem das nächste mal auftritt, sollte ich wahrscheinlich mal das SATA Kabel tauschen?

 

[PeterG]

Hi,
hattest Du die Platte vor dem Einbau vorbereitet? Evtl. muss die Platte mal Sektoren mappen und fliegt dadurch aus dem Raid. Das liesse sich durch entsprechendes Vorgehen zumindest ausschließen (dauert allerdings...).

Gruß
Peter

 

[massaquah]

Danke für den Tip.
Werd ich wohl mal testen. Was ich an der ganzen Geschichte allerdings komisch finde, ist, dass genau die Platte die Probleme macht, die von allen dreien die neuste ist und direkt aus der Verpackung kommt....

 

[PeterG]

Hi,
nee, genau deshalb mein Gedanke. Die anderen Platten laufen ja schon einige Zeit; da könnten defekte Sektoren schon remappt worden sein. Wenn die neue Platte gleich auf defekten Sektoren stößt, könnte das remapping zu Problemen führen (im Raid, sonst sollte das egal sein). Ist nur eine vage Möglichkeit... ich habe meine Platten alle vor dem Einbau einmal mit diskwipe behandelt...

Gruß
Peter

 

[massaquah]

Ich hab mir mal die /var/log/messages angeschaut von heute morgen nachdem das Problem zum letzten Mal aufgetreten ist.

Dabei sticht natürlich direkt folgendes ins Auge:

"Feb 26 08:01:07 kernel: md: kicking non-fresh sdc1 from array!"

Nur den Grund dafür kann ich da nicht rauslesen....

Feb 26 08:01:07 kernel: Synology Hardware Version: DS408v10-j
Feb 26 08:01:07 kernel: Internal HD num: 4
Feb 26 08:01:07 kernel: Internal netif num: 1
Feb 26 08:01:07 kernel: Found initrd at 0xbfefe000:0xbffacb90
Feb 26 08:01:07 kernel: Zone PFN ranges:
Feb 26 08:01:07 kernel:   DMA             0 ->   131072
Feb 26 08:01:07 kernel:   Normal     131072 ->   131072
Feb 26 08:01:07 kernel: Movable zone start PFN for each node
Feb 26 08:01:07 kernel: early_node_map[1] active PFN ranges
Feb 26 08:01:07 kernel:     0:        0 ->   131072
Feb 26 08:01:07 kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Feb 26 08:01:07 kernel: PID hash table entries: 2048 (order: 11, 8192 bytes)
Feb 26 08:01:07 kernel: Mount-cache hash table entries: 512
Feb 26 08:01:07 kernel: PCI: 0001:01:00.0: class b20 doesn't match header type 01. Ignoring class.
Feb 26 08:01:07 kernel: PCI: Cannot allocate resource region 0 of device 0001:02:00.0
Feb 26 08:01:07 kernel: Freeing initrd memory: 698k freed
Feb 26 08:01:07 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Feb 26 08:01:07 kernel: RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
Feb 26 08:01:07 kernel: Driver 'sd' needs updating - please use bus_type methods
Feb 26 08:01:07 kernel: PCI: Enabling device 0001:02:00.0 (0000 -> 0003)
Feb 26 08:01:07 kernel: Delay 10 seconds to wait for disk 1 ready.
Feb 26 08:01:07 kernel: Delay 10 seconds to wait for disk 2 ready.
Feb 26 08:01:07 kernel: Delay 10 seconds to wait for disk 3 ready.
Feb 26 08:01:07 kernel: Delay 10 seconds to wait for disk 4 ready.
Feb 26 08:01:07 kernel:  Amd/Fujitsu Extended Query Table at 0x0040
Feb 26 08:01:07 kernel: SYNOMTD-0: Swapping erase regions for broken CFI table.
Feb 26 08:01:07 kernel: Mac0: 00:11:32:02:3e:ab
Feb 26 08:01:07 kernel: Serial Number: 8BE9N00089
Feb 26 08:01:07 kernel: raid6: int32x1    125 MB/s
Feb 26 08:01:07 kernel: raid6: int32x2    210 MB/s
Feb 26 08:01:07 kernel: raid6: int32x4    277 MB/s
Feb 26 08:01:07 kernel: raid6: int32x8    222 MB/s
Feb 26 08:01:07 kernel: raid6: using algorithm int32x4 (277 MB/s)
Feb 26 08:01:07 kernel: md: sda2 has different UUID to sda1
Feb 26 08:01:07 kernel: md: sda3 has different UUID to sda1
Feb 26 08:01:07 kernel: md: sdb2 has different UUID to sda1
Feb 26 08:01:07 kernel: md: sdb3 has different UUID to sda1
Feb 26 08:01:07 kernel: md: sdc2 has different UUID to sda1
Feb 26 08:01:07 kernel: md: sdc3 has different UUID to sda1
Feb 26 08:01:07 kernel: md: kicking non-fresh sdc1 from array!
Feb 26 08:01:07 kernel: md: sda3 has different UUID to sda2
Feb 26 08:01:07 kernel: md: sdb3 has different UUID to sda2
Feb 26 08:01:07 kernel: md: sdc3 has different UUID to sda2
Feb 26 08:01:07 kernel: md: kicking non-fresh sdc3 from array!
Feb 26 08:01:07 kernel: raid5: raid level 5 set md2 active with 2 out of 3 devices, algorithm 2
Feb 26 08:01:07 kernel: RAID5 conf printout:
Feb 26 08:01:07 kernel:  --- rd:3 wd:2
Feb 26 08:01:07 kernel:  disk 0, o:1, dev:sda3
Feb 26 08:01:07 kernel:  disk 1, o:1, dev:sdb3
Feb 26 08:01:07 kernel: VFS: Mounted root (ext2 filesystem).
Feb 26 08:01:07 kernel: ds508_synobios: module license 'Synology Inc.' taints kernel.
Feb 26 08:01:07 kernel: Brand: Synology
Feb 26 08:01:07 kernel: Model: DS-408
Feb 26 08:01:07 kernel: synobios: unload
Feb 26 08:01:07 kernel: VFS: Mounted root (ext3 filesystem).
Feb 26 08:01:07 kernel: Freeing unused kernel memory: 152k init
Feb 26 08:01:07 kernel: Brand: Synology
Feb 26 08:01:07 kernel: Model: DS-408
Feb 26 08:01:07 s00_synocheckfstab: s00_synocheckfstab_main(240): /etc/fstab format error. szBuf=/dev/md2 /volume1 ext3 defaults 0 0
Feb 26 08:01:15 scemd: scemd.c:97 fan_type=3,  led_type=1, raid_type=1, dual_power_type=1, auto_poweron_type=1
Feb 26 08:01:15 scemd: modules/raid_sys_volume_check.c:146 MD0 active disks 2, designed disks 4 
Feb 26 08:01:15 scemd: modules/raid_sys_volume_check.c:146 MD1 active disks 3, designed disks 4 
Feb 26 08:01:15 scemd: modules/disk_hibernation.c:85 Force hibernation enable, idle minutes 60
Feb 26 08:01:15 synoprint: printer_device_open.c:16 bad parameter.
Feb 26 08:01:15 synousbdisk: RCClean succeeded
Feb 26 08:01:15 kernel: RAID1 conf printout:
Feb 26 08:01:15 kernel:  --- wd:2 rd:4
Feb 26 08:01:15 kernel:  disk 0, wo:0, o:1, dev:sda1
Feb 26 08:01:15 kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 26 08:01:15 kernel:  disk 2, wo:1, o:1, dev:sdc1
Feb 26 08:01:16 synocheckshare: share_update_right_map.c:65 Failed to get section [Diskstation] from /usr/syno/etc/share_right.map, (field count=5)
Feb 26 08:01:16 synocheckshare: share_set.c:291 Failed to update share naming Diskstation in share_right.map
Feb 26 08:01:16 synocheckshare: share_update_right_map.c:65 Failed to get section [public] from /usr/syno/etc/share_right.map, (field count=5)
Feb 26 08:01:16 synocheckshare: share_set.c:291 Failed to update share naming public in share_right.map
Feb 26 08:01:16 synocheckshare: service_user_home.c:276 SYNOShareRSectionRemove failed. synoerr=[0x2000]
Feb 26 08:01:16 ddnsd: main(ddnsd.c:1729):  not enable DDNS, shutdown daemon 
Feb 26 08:01:24 syno_hdd_util: Model:[HD103UJ], Firmware:[1AA01113], S/N:[S13PJDWS101468] in [/dev/sdc] is not ssd
Feb 26 08:01:24 syno_hdd_util: Model:[HD103UJ], Firmware:[1AA01113], S/N:[S13PJ1BQ736585] in [/dev/sdb] is not ssd
Feb 26 08:01:24 syno_hdd_util: Model:[HD103UJ], Firmware:[1AA01113], S/N:[S13PJ1BQ736591] in [/dev/sda] is not ssd
Feb 26 08:01:30 scemd: ScemRefreshDiskLed(438)Disk 4 not exist
Feb 26 08:02:02 kernel: RAID1 conf printout:
Feb 26 08:02:02 kernel:  --- wd:3 rd:4
Feb 26 08:02:02 kernel:  disk 0, wo:0, o:1, dev:sda1
Feb 26 08:02:02 kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 26 08:02:02 kernel:  disk 2, wo:0, o:1, dev:sdc1
Feb 26 08:03:35 scemd: scemd: power button pressed, ret = 0
Feb 26 08:03:35 scemd: SCEMD: Shutdown the system.
Feb 26 08:03:35 findhostd: si_pid=[3635], process=[/bin/sh]
Feb 26 08:03:35 findhostd: si_ppid=[3634], process=[sh]
Feb 26 08:03:35 findhostd: findhostd.c:51(FHOSTDExit) exit on signal[10] 
Feb 26 08:03:35 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd

EDIT:

Der Grund dafür scheint schon am Abend vorher aufzutreten. Beim automatischen Abschalten der DS kommt es anscheinend zu einem Fehler:

Feb 26 01:31:31 kernel: end_request: I/O error, dev sdc, sector 4276391
Feb 26 01:31:31 kernel: raid1: Disk failure on sdc1, disabling device. 
Feb 26 01:31:31 kernel: ^IOperation continuing on 2 devices
Feb 26 01:31:31 kernel: raid1: sdc1: rescheduling sector 4276328
Feb 26 01:31:31 kernel: sd 2:0:0:0: rejecting I/O to offline device
Feb 26 01:31:31 kernel: sd 2:0:0:0: rejecting I/O to offline device
Feb 26 01:31:31 kernel: md: super_written gets error=-19, uptodate=0
Feb 26 01:31:31 kernel: RAID1 conf printout:
Feb 26 01:31:31 kernel:  --- wd:2 rd:4
Feb 26 01:31:31 kernel:  disk 0, wo:0, o:1, dev:sda1
Feb 26 01:31:31 kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 26 01:31:31 kernel:  disk 2, wo:1, o:0, dev:sdc1
Feb 26 01:31:31 kernel: RAID1 conf printout:
Feb 26 01:31:31 kernel:  --- wd:2 rd:4
Feb 26 01:31:31 kernel:  disk 0, wo:0, o:1, dev:sda1
Feb 26 01:31:31 kernel:  disk 1, wo:0, o:1, dev:sdb1
Feb 26 01:31:31 scemd: modules/raid_sys_volume_check.c:236 Md0 degraded [2/4]
Feb 26 01:31:31 kernel: raid1: sdb1: redirecting sector 4276328 to another mirror
Feb 26 01:31:32 scemd: ScemRefreshDiskLed(445)Disk 3 fail
Feb 26 01:31:32 findhostd: si_pid=[3666], process=[/bin/sh]
Feb 26 01:31:32 findhostd: si_ppid=[3665], process=[sh]
Feb 26 01:31:32 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd
Feb 26 01:31:32 findhostd: findhostd.c:51(FHOSTDExit) exit on signal[10]

 

[itari]

Ja, da ist der Übeltäter: ein Sektor-Fehler. Genau das, was hier schon die ganze Zeit diskutiert wurde.

Itari

 

[massaquah]

Heute morgen (bzw. gestern abend) das gleiche Problem schon wieder. Diesmal ein komplett anderer Sektor.

Ich werd nun mal dieses "Vorbereiten" der Platte durchführen und ggf. das Kabel tauschen.

 

[schtiif]

Bei meiner DS207 hab ich genau das selbe Problem. Die DS207 findet Volume 1 nicht mehr und hängt sich danach auf. Nach einem Neustart ist V1 gar nicht mehr vorhanden.
Ich hab sie danach ausgebaut und in diesem Zustand mit HD Tune untersucht und keine Unstimmigkeiten gefunden. Auch der SMART Test ist i.O.!
Wo könnte noch ein Fehler sein? Ich glaube langsam fast an den Controller der Synology ... Dazu müsste ich mal die beiden Festplatten vertauschen und schauen, ob dann wieder V1 ausfällt. Das ist aber sehr zeitaufwändig.

Hat jemand sonst eine Idee?

 

[massaquah]

Nachdem ich alles versucht hatte, von dem beschriebenen "Vorbereiten" der Platten, bis hin zum Vertauschen, Kabel Austausch etc. war am Ende die Lösung ganz einfach die, dass die Samsung F1 wohl zurecht nicht auf der Kompatibilitätsliste der DS408 steht.

Nachdem ich die drei Samsungs gegen 3 neue WD greens getauscht hatte, läuft nun seit Monaten alles tacko.

Die Samsung Platten sind übrigens völlig in Ordnung. Die verrichten jetzt bei nem Kollegen an nem internen Raidcontroller problemlos ihre Arbeit.