DS209+ Volume stürzt beim Erweitern ab

[JCDenton]

Hallo,

ich habe heute in meiner DS209+ (läuft im Raid 1) die zwei Seagate ST31000340AS (1 TB) gegen zwei neue Samsung Spinpoint EcoGreen F2 HD154UI (1.5 TB) ausgetauscht, undzwar in folgender Weise:

1. Austausch der Platte #1 und Neusynchronisieren des Volumes (erfolgreich)
2. Austausch der Platte #2 und Neusynchronisieren des Volumes, ging bis 100% und kurz danach meldete der Volume Manager, dass das Volume 1 abgestürzt ist und die DS begann auch orange zu blinken und zu piepen, da hab ich schon nen Schreck bekommen...
3. Manueller Neustart der DS, danach kein Piepen mehr und alles grün; der Volume Manager meint dass das Volume 1 in einwandfreiem Zustand ist, beide neuen Platten befinden sich im Zustand "Normal", ein SMART-Test bringt auch keine Auffälligkeiten.

So weit so gut...

Nun sind die neuen Platten ja beide 1.5 TB groß, weshalb ich das Volume 1 nun erweitern wollte mit dem noch verfügbaren Speicherplatz, was mir der Volume Manager auch vorschlägt.

Also Verwalten -> Erweitern ausgewählt und los geht's ... dann kommt der Fortschritt, dass alle Dienste beendet werden und die Erweiterung begonnen wird ... während immer noch 0.00% da steht, meldet plötzlich der Volume Manager wieder, dass das Volume 1 abgestürzt sei ... und das Verhalten von oben (siehe Punkt 3) beginnt wieder.
Nach einem Neustart ist wieder alles gut, aber die Größe hat sich nicht verändert.

In /var/log/messages, steht folgendes:

...
Apr 18 00:17:17 kernel: force close debug file(1) dentry(1)
Apr 18 00:17:17 kernel: force close syslog file(1) dentry(1)
Apr 18 00:17:17 kernel: force close libevtlog.so.0.0.0 file(3) dentry(1)
Apr 18 00:17:17 kernel: force close libglib-2.0.so.0.2000.4 file(3) dentry(1)
Apr 18 00:17:17 kernel: force close libnsl-2.3.4.so file(3) dentry(1)
Apr 18 00:17:17 kernel: force close syslog-ng file(2) dentry(1)
Apr 18 00:17:17 kernel: force umount failed! mnt_count:22
Apr 18 00:17:23 scemd: fs_expand_progress.c:47 Retry 5 times to wait process alive. Give up!!
Apr 18 00:17:25 scemd: space_info_enum.c:475 Failed to get fs expand progress with '/dev/md2', errno=0x3400
Apr 18 00:17:31 scemd: fs_expand_progress.c:47 Retry 5 times to wait process alive. Give up!!
Apr 18 00:17:32 scemd: space_info_enum.c:475 Failed to get fs expand progress with '/dev/md2', errno=0x3400
Apr 18 00:17:34 scemd: modules/raid_data_volume_check.c:812 Volume /volume1 crashed, mount it read-only
Apr 18 00:17:44 scemd: volume_remount.c:40 Failed to remount '/volume1' to 'ro', WEXITSTATUS(err) = 1, err = 256
Apr 18 00:17:44 scemd: volume_crashed_handler.c:40 Failed to remount '/volume1' to read-only
Apr 18 00:18:06 scemd: modules/raid_data_volume_check.c:885 /volume1 state changes from 0 to 3.

Woran kann das liegen? Was kann ich machen, um das Volume 1 zu vergrößern?

Danke!

JCDenton

 

[JCDenton]

Hmm ... könnte das was mit IPKG zu tun haben? Muss ich wohl versuchen das auszuschalten bzw. /opt manuell unmounten, wie es in anderen Threads bereits beschrieben wurde?

 

[JCDenton]

Moin,

also der Hinweis von goetz im Thread

http://www.synology-forum.de/showthread.html?t=8898&page=3

hat funktioniert! Es reichte einfach aus, den Verweis auf das Startscript der optware kurz auszukommentieren und neuzustarten - dann läuft die Erweiterung des Volumes problemlos durch.

Danke!

 

[eyeball]

Hi,

bei meiner CS407 ist gerade genau das gleiche passiert. Übrigens mit derselben Disk Samsung Spinpoint EcoGreen F2 HD154UI (1.5 TB). Ich habe die alten 320 GB Platten nach und nach durch die neuen ersetzt. Bei den ersten drei Platten ging das problemlos. Bei der vierten gab es keine Meldung, dass die Reparatur erfolgreich war, sondern es startete ein erneuter Repair Prozess, der diesmal knapp 20 Stunden dauerte. Danach wurde versucht, das Volume zu vergößern, was mit einem Crash von volume1 endete. Beim Vergrößern zeigte die Cubestation bereits die neue Größe (4 TB) an, aber die Belegung war 0%. Leider habe ich zu spät ins Forum geguckt und mit der Neuerrichtung des Volumes begonnen, so dass eine Rettung nicht mehr möglich ist.
Auf jeden Fall scheint etwas mit der Repair-Funktion nicht zu stimmen (DSM 2.3-1139).

Viele Grüße.
Dirk