Hallo zusammen,
folgende Ausgangssituation:
DS212+, DSM 5.1-5022 Update 4, mit zwei WD green 2 TB Platten in RAID1 Mode auf einem Volume.
Nach 3 Jahren hardwareseitig störungsfreiem Dauerbetrieb und nun zu 90% vollen Platten (Smartwerte der alten Platten sind fehlerfrei) Entschluss zum Tausch gegen zwei neue WD green 4 TB Platten.
Sicherungen von Daten und konfigurationen erstellt.
Vorgehen:
Schritte laut Synology Anleitung:
- DS runterfahren
- erste Platte tauschen
- DS hochfahren
- über Web-Interface / Speichermanager / Volume reparieren
- nach ca. 10 Stunden Platte fehlerfrei gespiegelt
- DS wieder runuterfahren
- zweite platte tauschen
- DS hochfahren
- Web-Interface / Speichermanager Volume reparieren
- bei ca. 30% Fortschritt ins Bett gegangen...
Hier endet zunächst mal der planmäßige Prozess.
Nach weiteren ca. 10 Stunden Kontrollversuch um Status festzustellen.
Ich konnte mich über das Web-interface nicht mehr anmelden. SSH-Zugang hatte ich leider nicht geöffnet. Ping-Anfragen hat die DS beantwortet.
Nachdem nun - verglichen mit der Synchronisierung der ersten Platte - genügend zeit vergangen war, entschloss ich mich dazu, die DS über den Power-Off Schalter runter zu fahren (blaues LED blink). Nach 10 Stunden war der Shutdown immer nicht abgeschlossen.
=> Ausschalten durch Stromabschaltung.
Neustart: DS fährt hoch, Volume wieder fehlerhaft. Erneutes reparieren, diesmal bei 90% Fertigstellungsgrad schlafen gegangen. Am nächsten morgen DS wieder nicht erreichbar. Weder per Web-Interface noch über den (mittlerweile aktivierten) SSH-Zugang. Shutdown-Versuch via Power-Off nach 30 min immer noch nicht abgeschlossen.
=> Erneutes Ausschalten durch Stromabschaltung.
Neustart: DS fährt hoch, Status des Volumes im Speichermanager "Normal". Vorschlag des Speichermanagers: Volume kann erweitert werden.
Verzweigen nach Verwalten => Volume erweitern und so die Erweiterung manuell angestoßen. nach ca. 1-2 min. verabschiedet sich das Webinterface. Ebenso wieder kein Zugang per SSH.
=> Strom aus / Strom an...
Jetzt Anmeldung über SSH und fleißig im Netz gestöbert.
Habe hierdurch ein bisschen was über die Partitionierung auf der DS erfahren. Nun Teile diverser Postings ausgeführt, um Informationen zu sammeln. Bisher keine Änderungen via Konsole vorgenommen.
Hier die Infos, die ich für evtl. bedeutsam halte.
Zunächst für die drei RAID Partitionen das Filesystem gecheckt:
/dev/md0 (Systempartition?):
e2fsck -nvf -C 0 /dev/md0
Auf der Systempartition scheinen ein paar Blocks und Inodes durcheinander gekommen zu sein. Da es sich um die Systempartition handelt und die DS immer noch vermeintlich stabil läuft ist das möglicherweise nicht von essentieller Bedeutung.
/dev/md1 (Swap-Partition?):
e2fsck -nvf -C 0 /dev/md1
Die Fehler sind bei der Swap-Partition wohl egal?
/dev/md2 (Volume-Partition?):
e2fsck -nvf -C 0 /dev/md2
Die Volume-Partition scheint sauber zu sein.
Nun nach den Größen der Partitionen geschaut:
cat /proc/partitions
Hieraus lese ich, dass die physischen Partitionen auf den beiden Festplatten sda3 und sdb3 wohl schon vergrößert sind, die zusammengefasste RAID-Partition jedoch noch nicht.
Nun der erste Änderungsversuch per Konsole (/dev/md2 direkt vergößern):
Erst Dienste anhalten:
syno_poweroff_task -d
Und nun versuchen, /dev/md2 direkt zu vergrößern was bei ext4 laut dieser Quelle auch während des Betriebs möglich sein sollte:
resize2fs -p /dev/md2
Ab jetzt weiß ich leider nicht mehr, was ich weiter machen soll.
Deshalb zunächst ein paar Fragen in die Runde.
/dev/md0:
- Kann es sein, dass die fehlerhafte Systempartition /dev/md0 an der Misere schuld ist?
- Wie kann ich die DS dazu bringen, die Fehler im Dateisystem /dev/md0 beim Hochfahren zu korrigieren?
- Wie müssen / sollen die Fehler auf /dev/md0 korrigiert werden, ohne das ext4 Dateisystem zu anderweitig zu beschädigen?
/dev/md1:
- Sind die Prüfungsergebnisse für eine Swap-Partition ok?
- Wenn nicht, wie ist die Partition zu korrigieren?
/dev/md2, der (hoffentlich) eigentliche Problemfall:
- Wie bekomme ich das das Volume vergrößert?
Ich wäre sehr dankbar, wenn ich hier qualifizierten Ratschläge erhalten könnte.
folgende Ausgangssituation:
DS212+, DSM 5.1-5022 Update 4, mit zwei WD green 2 TB Platten in RAID1 Mode auf einem Volume.
Nach 3 Jahren hardwareseitig störungsfreiem Dauerbetrieb und nun zu 90% vollen Platten (Smartwerte der alten Platten sind fehlerfrei) Entschluss zum Tausch gegen zwei neue WD green 4 TB Platten.
Sicherungen von Daten und konfigurationen erstellt.
Vorgehen:
Schritte laut Synology Anleitung:
- DS runterfahren
- erste Platte tauschen
- DS hochfahren
- über Web-Interface / Speichermanager / Volume reparieren
- nach ca. 10 Stunden Platte fehlerfrei gespiegelt
- DS wieder runuterfahren
- zweite platte tauschen
- DS hochfahren
- Web-Interface / Speichermanager Volume reparieren
- bei ca. 30% Fortschritt ins Bett gegangen...
Hier endet zunächst mal der planmäßige Prozess.
Nach weiteren ca. 10 Stunden Kontrollversuch um Status festzustellen.
Ich konnte mich über das Web-interface nicht mehr anmelden. SSH-Zugang hatte ich leider nicht geöffnet. Ping-Anfragen hat die DS beantwortet.
Nachdem nun - verglichen mit der Synchronisierung der ersten Platte - genügend zeit vergangen war, entschloss ich mich dazu, die DS über den Power-Off Schalter runter zu fahren (blaues LED blink). Nach 10 Stunden war der Shutdown immer nicht abgeschlossen.
=> Ausschalten durch Stromabschaltung.
Neustart: DS fährt hoch, Volume wieder fehlerhaft. Erneutes reparieren, diesmal bei 90% Fertigstellungsgrad schlafen gegangen. Am nächsten morgen DS wieder nicht erreichbar. Weder per Web-Interface noch über den (mittlerweile aktivierten) SSH-Zugang. Shutdown-Versuch via Power-Off nach 30 min immer noch nicht abgeschlossen.
=> Erneutes Ausschalten durch Stromabschaltung.
Neustart: DS fährt hoch, Status des Volumes im Speichermanager "Normal". Vorschlag des Speichermanagers: Volume kann erweitert werden.
Verzweigen nach Verwalten => Volume erweitern und so die Erweiterung manuell angestoßen. nach ca. 1-2 min. verabschiedet sich das Webinterface. Ebenso wieder kein Zugang per SSH.
=> Strom aus / Strom an...
Jetzt Anmeldung über SSH und fleißig im Netz gestöbert.
Habe hierdurch ein bisschen was über die Partitionierung auf der DS erfahren. Nun Teile diverser Postings ausgeführt, um Informationen zu sammeln. Bisher keine Änderungen via Konsole vorgenommen.
Hier die Infos, die ich für evtl. bedeutsam halte.
Zunächst für die drei RAID Partitionen das Filesystem gecheckt:
/dev/md0 (Systempartition?):
e2fsck -nvf -C 0 /dev/md0
Rich (BBCode):
Data-Engine> e2fsck -nvf -C 0 /dev/md0
e2fsck 1.42.6 (21-Sep-2012)
Warning! /dev/md0 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (423836, counted=423848).
Fix? no
Free inodes count wrong (120167, counted=119638).
Fix? no
35481 inodes used (22.80%, out of 155648)
186 non-contiguous files (0.5%)
13 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 31595/51
198708 blocks used (31.92%, out of 622544)
0 bad blocks
1 large file
27400 regular files
3208 directories
76 character device files
1613 block device files
0 fifos
1431 links
3703 symbolic links (2666 fast symbolic links)
1 socket
------------
37432 files
Data-Engine>Auf der Systempartition scheinen ein paar Blocks und Inodes durcheinander gekommen zu sein. Da es sich um die Systempartition handelt und die DS immer noch vermeintlich stabil läuft ist das möglicherweise nicht von essentieller Bedeutung.
/dev/md1 (Swap-Partition?):
e2fsck -nvf -C 0 /dev/md1
Rich (BBCode):
Data-Engine> e2fsck -nvf -C 0 /dev/md1
e2fsck 1.42.6 (21-Sep-2012)
Warning! /dev/md1 is mounted.
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/md1
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>
Data-Engine>Die Fehler sind bei der Swap-Partition wohl egal?
/dev/md2 (Volume-Partition?):
e2fsck -nvf -C 0 /dev/md2
Rich (BBCode):
Data-Engine> e2fsck -nvf -C 0 /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
685180 inodes used (0.56%, out of 121806848)
4978 non-contiguous files (0.7%)
308 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 680033/1799/3
453375990 blocks used (93.06%, out of 487198064)
0 bad blocks
182 large files
573616 regular files
108046 directories
4 character device files
0 block device files
3 fifos
539 links
3477 symbolic links (3305 fast symbolic links)
25 sockets
------------
685710 files
Data-Engine>Die Volume-Partition scheint sauber zu sein.
Nun nach den Größen der Partitionen geschaut:
cat /proc/partitions
Rich (BBCode):
Data-Engine> cat /proc/partitions
major minor #blocks name
8 0 3907018584 sda
8 1 2490240 sda1
8 2 2097152 sda2
8 3 3902197584 sda3
8 16 3907018584 sdb
8 17 2490240 sdb1
8 18 2097152 sdb2
8 19 3902197584 sdb3
31 0 512 mtdblock0
31 1 2048 mtdblock1
31 2 1280 mtdblock2
31 3 64 mtdblock3
31 4 128 mtdblock4
31 5 64 mtdblock5
31 6 4096 mtdblock6
9 0 2490176 md0
9 1 2097088 md1
9 2 1948792256 md2
65 0 1465138584 sdq
65 1 1465135904 sdq1
65 32 976762584 sds
65 33 976759904 sds1
Data-Engine>Hieraus lese ich, dass die physischen Partitionen auf den beiden Festplatten sda3 und sdb3 wohl schon vergrößert sind, die zusammengefasste RAID-Partition jedoch noch nicht.
Nun der erste Änderungsversuch per Konsole (/dev/md2 direkt vergößern):
Erst Dienste anhalten:
syno_poweroff_task -d
Rich (BBCode):
Data-Engine> syno_poweroff_task -d
hotplugd stop/waiting
synonetd stop/waiting
synostoraged stop/waiting
synologrotated stop/waiting
webstation-httpd-conf-writer stop/waiting
nmbd stop/waiting
smbd stop/waiting
synomkflvd stop/waiting
dc-output stop/waiting
job-monitor-handler stop/waiting
synovpnclient stop/waiting
webdav-httpd-ssl stop/waiting
updateindexdb-adapter stop/waiting
WDidle3Dis stop/waiting
nginx stop/waiting
RCPower stop/waiting
crond stop/waiting
fileindex stop/waiting
php-fpm-3rdparty stop/waiting
DiskHealthCk stop/waiting
nfsd-adapter stop/waiting
synobackupd stop/waiting
php-fpm stop/waiting
ntpd stop/waiting
updatesynohdpack-adapter stop/waiting
s2s_daemon stop/waiting
syslog-acc stop/waiting
syslog-notify stop/waiting
synomkthumbd stop/waiting
img_backupd stop/waiting
httpd-sys stop/waiting
webdav-httpd stop/waiting
httpd-user stop/waiting
Data-Engine>Und nun versuchen, /dev/md2 direkt zu vergrößern was bei ext4 laut dieser Quelle auch während des Betriebs möglich sein sollte:
resize2fs -p /dev/md2
Rich (BBCode):
Data-Engine> resize2fs -p /dev/md2
resize2fs 1.42.6 (21-Sep-2012)
The filesystem is already 487198064 blocks long. Nothing to do! (Device size is 487198064 blocks long)
Data-Engine> rebootAb jetzt weiß ich leider nicht mehr, was ich weiter machen soll.
Deshalb zunächst ein paar Fragen in die Runde.
/dev/md0:
- Kann es sein, dass die fehlerhafte Systempartition /dev/md0 an der Misere schuld ist?
- Wie kann ich die DS dazu bringen, die Fehler im Dateisystem /dev/md0 beim Hochfahren zu korrigieren?
- Wie müssen / sollen die Fehler auf /dev/md0 korrigiert werden, ohne das ext4 Dateisystem zu anderweitig zu beschädigen?
/dev/md1:
- Sind die Prüfungsergebnisse für eine Swap-Partition ok?
- Wenn nicht, wie ist die Partition zu korrigieren?
/dev/md2, der (hoffentlich) eigentliche Problemfall:
- Wie bekomme ich das das Volume vergrößert?
Ich wäre sehr dankbar, wenn ich hier qualifizierten Ratschläge erhalten könnte.
