RAID5 Diskgruppe mit einer Disk erweitert, danach stimmte das Volume nicht mehr

[In0cenT]

Tag zusammen

Situation vor dem erweitern:
- RAID5
- 7x WD RED 4TB
- Volume zu 100% ausgelastet
- DSM 5.2-5592

Die Diskgruppe wurde mit einer neuen WD RED 4TB erweitert. Nach dem erweitern hatte das Volume nur noch eine Grösse von 5.72TB an.
http://snag.gy/yJrC4.jpg

Die Diskgruppe zeigt jedoch die korrekte Grösse an:
http://snag.gy/H6MuN.jpg

Ich erhalte nach einem Neustart die Meldung: "File system error was found on volume [1]". Beim wählen der ersten Option startet das NAS neu und kommt nach ca. 1h wieder zurück. Jedoch ohne Erfolg und der Fehler bleibt bestehen.

Normale Reboots haben auch nichts gebracht.

Alle Daten scheinen noch vorhanden zu sein und Funktionieren. Das Volume ist nicht vergrösserbar, da ein Fehler auf dem Volume vorhanden ist.


Wie ist mein Volume noch rettbar?

Grüsse

 

[goetz]

Hallo,
schau mal hier, ab etwa der Mitte ist eine Anleitung zum Filesystem Check.

Gruß Götz

 

[In0cenT]

Ciao goetz

Gleich nach deiner Antwort habe ich den Befehl "syno_poweroff_task -d" ausgeführt. Nun ist er immer noch nicht fertig, grob gesagt 1.5h später...

Dies ist nicht normal oder?

Grüsse


Update 16:19:
Habe den poweroff Befehl mal unterbrochen und mal die Befehle ausgeführt.

Fileserver> vgchange -ay
2 logical volume(s) in volume group "vg1" now active
Fileserver> fsck.ext4 -pvf -C0 /dev/vg1/lv
fsck.ext4: No such file or directory while trying to open /dev/vg1/lv
Possibly non-existent device?
Fileserver> ls -d
.
Fileserver> cd /
Fileserver> ls -d
.



Was kann ich noch probieren?

 

[goetz]

Hallo,
schau ob es vg1 gibt
ls -d /dev/vg*
und welche devices in vg1 sind bzw. falls es anders heißen sollte dann dort
ls -la /dev/vg1

Gruß Götz

 

[In0cenT]

Ciao

Danke für deine Hilfe!


Fileserver> ls -d /dev/vg*
/dev/vg1 /dev/vga_arbiter
Fileserver> fsck.ext4 -pvf -C0 /dev/vg1
fsck.ext4: Is a directory while trying to open /dev/vg1
/dev/vg1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>



Soll ich so weiterfahren wie es von der Konsole vorgeschlagen ist?
Möchte nichts unüberlegtes tun...

Grüsse

 

[goetz]

Hallo,
schau erst mal was in /dev/vg1 liegt
ls -la /dev/vg1
und ob da etwas ist
ls -la /dev/mapper

Gruß Götz

 

[In0cenT]

http://snag.gy/fXHIV.jpg

 

[goetz]

Hallo,
dann geht es mit

fsck.ext4 -pvf -C0 /dev/mapper/vg1-volume_1

weiter.

Gruß Götz

 

[In0cenT]

Wie unmounte ich das Volume am besten?


Fileserver> fsck.ext4 -pvf -C0 /dev/mapper/vg1-volume_1
/dev/mapper/vg1-volume_1 is mounted.
e2fsck: Cannot continue, aborting.


Fileserver> umount /dev/mapper/vg1-volume_1
umount: can't umount /volume1: Device or resource busy
Fileserver> ls -la /dev/mapper/vg1-volume_1
brw------- 1 root root 253, 1 Mar 7 15:06 /dev/mapper/vg1-volume_1
Fileserver>

 

[goetz]

Hallo,
das sollte eigentlich syno_poweroff_task -d erledigen, hat dann aber wohl nicht geklappt.
Ich würde im Paketmanager alle Paket auf Stopp setzen. Hast Du ipkg installiert oder eigene mount ---bind angelegt?
Im DSM abmelden und noch mal syno_poweroff_task -d

Gruß Götz

 

[In0cenT]

Versuche das gleiche über die Nacht nochmals, musste einen Neustart machen und jetzt führt es wieder die Bereinigung durch....

http://i.snag.gy/uWTaO.jpg

 

[goetz]

Hallo,
das ist jetzt die Bereinigung vom System aus? Wenn ja so ist das nichts anderes als
fsck.ext4 -pvf -C0 /dev/mapper/vg1-volume_1
fsck.ext4 ist ein Symlink auf e2fsck.
Wenn sich der Zustand nicht ändert würde ich
fsck.ext4 -yvf -C0 /dev/mapper/vg1-volume_1
nutzen. Wenn ich mich recht erinnere hatte ich auch schon mal ein Problem mit dem Filesystem und automatische Reparatur (-p) hat nicht geholfen, erst ein Durchlauf mit alle Fragen mit ja beantworten (-y) hat geholfen.

Gruß Götz

 

[In0cenT]

Das Cloud Station brachte mir viele Probleme ein. Prozesse liefen auf 99%, auch wenn dies nicht laufen sollte. Wurde deinstalliert und nun ging der syno_poweroff_task -d innert Sekunden durch.

Lasse gerade die Checks laufen, werde mich vermutlich erst morgen wieder melden. Dauert ja eine Weile...