Volume 1 - Abgestürzt; Diese Volume kann nicht verwendet werden.... ???

[deb10042]

Bitrot? Nie gehört

 

[deb10042]

Du kannst über ssh versuchen das Volume zu reparieren, dazu neustart
ssh login
sudo -i cat /proc/mdstat
Das richtige Volume identifizieren
sudo btrfs check --repair /dev/???
wahrscheinlich: sudo btrfs check --repair /dev/md2

Hi,
könntest Du mir bitte grad nochmal erklären, wie "Das richtige Volume identifizieren" funktioniert?

Wenn ich den Befehlt
"cat /proc/mdstat"
ausführe, kommt das im Anhang oben gezeigte Resultat raus.

Führe ich
"cat /etc/fstab"
aus, erhalte ich das im selben Anhang unten angezeigte Ergebnis.

Ist damit die Volumens-Bezeichnung bei mir nicht "/dev/vg1000/lv" und der entsprechende "check-Befehl" müsste
"sudo btrfs check --repair /dev/vg1000/lv"
lauten?

(Sorry für die blöde Frage, aber die Kommandozeile ist halt nicht meine "Heimat" )

 

[Benares]

Du hast wohl einen SHR-Pool mit 2 Platten. Ohne SHR wäre /dev/md2 das Device für deinen Datenbereich. Mit SHR ist es /dev/vg1000/lv, da noch ein Logical Volume Manager (LVM) dazwischen hängt. "sudo btrfs check --repair /dev/vg1000/lv" ist daher richtig.

 

[deb10042]

Dankeschön!

 

[deb10042]

Uff, die Fragen reißen leider nicht ab
Wenn ich den "repair-Befehl", wie oben genannt, eingebe, dann erhalte ich:
"/dev/vg1000/lv is currently mounted. Aborting."
Ich dachte eigentlich, dass ein Volume, das "abgestürzt" ist, auch "unmounted" ist.
Nachdem das offensichtlich nicht der Fall ist, kann ich dann überhaupt eine Reparatur über die Kommandozeile starten?
Oder ist der einzig mögliche Weg doch nur noch der, auf die DSM-Oberfläche und in den Speicher-Manager zu gehen und beim Volume auf den "Entfernen"-Button zu klicken?

 

[Benares]

Nein, das Filesystem bleibt schon gemountet. Du kannst aber m.W. mit "syno_poweroff_task -d" (DSM6) bzw. "synospace --stop-all-spaces" (DSM7) alles stoppen, was noch darauf zugreift und den umount erzwingen. Achte nur darauf, dass du nicht selbst noch im Filesystem stehst, also z.B. mit "cd /" vorher auf / wechseln.

 

[deb10042]

Das funktioniert bei mir leider nicht.
Nach Eingabe des Befehls "syno_poweroff_task -d" (ich habe DSM 6.2....) dauert es eine Weile und danach erhalte ich
"Connection to 192......... closed." und auch meine ssh-Session ist zu Ende.
Wenn ich dann erneut reingehe und den "repair"-Befehl ausführe, endet dieser wieder mit "Aborting".

 

[Benares]

Mmh, da bin ich überfragt. Hab's noch nie selbst probiert. Vielleicht wissen andere mehr.

Edit: Googel mal nach "synology btrfs check", da gibt es einiges.

 

[deb10042]

Nach einigen erfolglosen Versuchen ist es mir nun gelungen, den "repair"-Befehl anzustoßen.
Es hat anscheinend damit zu tun, ob man via ssh nur als admin angemeldet ist, oder auch root-Zugriff hat.

Es lief jetzt jedenfalls ein Reparaturvorgang durch und es gab auch eine ganze Menge Einträge, wie z.B.:

bad key ordering 74 75
incorrect offsets 13841 13808
Shifting item nr 84 by 33 bytes in block 6024828518400
Deleting bogus item [2305844821203075072,169,0] at slot 158 on block 6024828518400
corrupt extent record: key 1811989430272 169 16384
ref mismatch on [1811989381120 16384] extent item 0, found 1
adding new tree backref on start 1811989381120 len 16384 parent 0 root 261
Backref 1811989381120 parent 261 root 261 not found in extent tree
backpointer mismatch on [1811989381120 16384]

(Das sind nur zeilenweise Auszüge aus der Gesamtanzahl von Meldungen, die der Repair-Vorgang ausgeworfen hat.)

Am Ende dann diese Zeilen... ist mir jetzt nicht so richtig klar, was das alles bedeutet, aber ich werde nachher mal die DS neu starten und sehen, ob sich etwas geändert hat:

repaired damaged extent references
Fixed 0 roots.
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 17108717608960 bytes used err is 0
total csum bytes: 5657376752
total tree bytes: 9265889280
total fs tree bytes: 2473754624
total extent tree bytes: 579911680
btree space waste bytes: 1055650683
file data blocks allocated: 6820128526336
referenced 5749530529792


Edit - 5 Minuten später:

Die DS funktioniert (momentan ) wieder!
Die Status-LED war nach dem Restart gleich grün und Volume, Pool und Platten werden (derzeit) als i.O. angezeigt.
Die Fotostation funktioniert wieder, die Notestation synchronisiert wieder, alle anderen Pakete werden auch wieder als "Läuft" angezeigt und Schreiben im File System funktioniert ebenfalls wieder...

Momentan rattern die Festplatten immer noch etwas vor sich hin; wer weiß, ob da noch irgendwelche Reparatur-, Indizierungs- oder Synchronisierungs-Prozesse laufen.
Ich bin gespannt, ob der Zustand der DS so bleibt, oder ob es in absehbarer Zeit wieder zu Fehlern kommt.

Habt ihr noch Ideen, welche Tests ich auf der derzeit also wieder laufenden DS noch durchführen kann und sollte, um zu überprüfen, ob nun in meinem Dateisystem oder im Betriebssystem noch irgendwelche "faulen Äpfel rumliegen"?
Ich denke, ein neuerlicher SMART-Test wird nicht viel bringen, denn den habe ich im erweiterten Modus erst kurz vor der heutigen Reparatur-Aktion durchgeführt (ohne zusätzlich negative Erkenntnisse).

 

[ctrlaltdelete]

keine smart test machen, einfach mal schauen wie es weiter geht.

 

[deb10042]

OK, dann an dieser Stelle nochmal VIELEN DANK an Euch!
Sollte es zu weiteren Problemen kommen, werde ich hier berichten

PS: Gewaschenes Kind scheut das Wasser... die neue DS720+ steht jetzt hier zusätzlich auf dem Schreibtisch und ich habe sie gerade mit 2 Stück WD Red Plus 12TB bestückt. Allerdings zickt auch diese Kiste rum und erlaubt mir derzeit kein Volume zu erstellen - grrrrrr (aber das ist wieder eine andere/neue Geschichte)

 

[deb10042]

PS2: Und danke für den "Tritt" in Richtung USV... die steht nun auch konfigurationsbereit hier auf meinem Schreibtisch (ist eine "Eaton Ellipse Eco 650 USB DIN" geworden)