gelöst: File system error was found on volume....

rumknapser

Benutzer
Mitglied seit
02. Mai 2013
Beiträge
329
Punkte für Reaktionen
6
Punkte
24
Hallo,
ich hatte vor, während und nach der Speicherkapazitätserweiterung meiner DS1813+ von 8x4TB auf 8x6TB Probleme mit der Datenkonsistenz.

Diese Probleme äußerten sich derart, das ich täglich Fehlermeldungen dieser Art bekam: File system error was found on volume[1]
Anhang anzeigen 25123

Fast ausschließlich, wenn Daten auf das NAS geschrieben wurden. im Ruhezustand (kein Standby, es wurden nur nicht aktiv Daten gelesen oder geschrieben) oder spontan kamen eigentlich keine Fehlermeldungen hoch.

Fehler an den (neuen) Festplatten konnte ich mithilfe der helfenden User hier ausschliessen.

Die DS bot mir manchmal an, dass ein Neustart mit anschliessender Datenüberprüfung den Fehler beheben könnte, was aber -nach bestimmt 30 Reboots und (jeweils mehrstündigen) Checks- nicht geschah, d.h. die Fehlermeldungen kamen weiterhin, wenn auf das Hybrid SHR-RAID6 geschrieben wurde (via SMB oder NFS).
f4.jpg

Interessanterweise, nachdem alle "kleinen" Festplatten durch die größeren und neuen ersetzt wurden, bot mir die DS zwar an, den neuen Speicherplatz auch zu erweitern, brach aber immer schon vor dem eigentlichen Vorgang ab mit der Meldung, dass das Dateisystem Fehler enthalte und ich doch bitte einen Check durchlaufen lassen solle.


Leider gab es aber NIRGENDS die Möglichkeit dazu, wie hier auf dem Screenshot wunderbar auszuwählen:
f7.png
Auf diesem Screenshot wird mir "Reparieren" angeboten, allerdings war diese Möglichkeit nur aktiviert, nachdem jede einzelne neue Platte im Raid6-Verbund aufgenommen und integriert wurde. Nachdem also alle Platte umgebaut waren und ich den Speicherplatz vergrößern wollte, war diese Option ausschliesslich ausgegraut und nicht anwählbar. Egal, welche Reihenfolge von Klicks ich ausprobiert habe. Eindeutig ein trauriger Zustand, der es dem User nicht ermöglicht, via WebGUI einen Dateisystem-Check auszuführen, obwohl das Dateisystem anscheinend keinen sollchen erkannt hat.)


Auch die Option "Datenbereinigung starten", wie hier schön zu sehen und auszuwählen, war nicht vorhanden:
f6.png


Die Option "Das Volume mit nicht zugewiesenen Festplattenspeicherplatz erweitern" wie hier auf dem Screenshot zu sehen, führte, wie erwähnt, nur dazu, das bemerkt wurde, das Dateiinkonsistenzen vorlägen und diese doch bitte zuerst behoben werden sollen.... nur wie denn, wenn die WebGUI nix derartiges anbietet? ;-)


Hier und hier im Forum habe ich einige Meldungen, die diesen Zustand ähnlich umschreiben gefunden, allerdings keine reproduzierbare Lösung für mich angeboten haben.
Ein Mensch meine auch, er hätte kurz eine Platte aus der DS gezogen und dann wieder reingesteckt, dann waren die Probleme erledigt.

Habe ich ausprobiert, hat aber nicht wirklich geholfen :)
Ergebnis war dieses:
Anhang anzeigen 25124
Allerdings brachte der Scan auch keine Besserung.


Hier noch -der vollständigkeithalber- drei Screenshots der Meldungen, die ich bezüglich der Dateisystemfehler bekam, bis ich dann meine Lösung niederschreibe:
f5.jpg
f3.jpg


Funktionierende Hilfe fand ich dann hier im englischen Synology-Forum in diesem Thread.

Der passende Teil, der auf der Kommandozeile/im Terminal eingehackt werden muss, ist dieser:
Rich (BBCode):
    syno_poweroff_task -d [Press Enter] << This will bring down all services except the SSH.

    vgchange -ay [Press Enter] << This will enable the volume

    fsck.ext4 -pvf -C0 /dev/vg1/lv [press Enter] << This will try to fix the error, pop out yes/no to let you chose when error show up.

    fsck.ext4 -yvf -C0 /dev/vg1/lv [Press Enter] << This will try to fix the error, system will automatic chose yes to fix error.


    If -pvf can't work, please use -yvf instead. After the command fsck is completed, please reboot your DS with the reboot command.

Kurz beschrieben, werden hier mit dem Befehl "syno_poweroff_task -d" alle Dienste der DS heruntergefahren, ausser dem SSH-Dienst, über den man ja eingeloggt auf der Konsole ist.
Das Volume auf dem Raid, auf dem meine Daten gespeichert sind und welches wohl auch heruntergefahren wird mit obigen Befehl, wird dann aktiviert mit diesem Befehl "vgchange -ay" und geprüft/repariert mit den beiden letztzten Befehlen (fsck...). (Bitte berichtigt mich, wenn ich hier falsch interpretiere...)

Wobei man beim Namen "/dev/vg1/lv" des Volumes auf Schwierigkeiten stoßen könnte, weil der Name wohl je nach DS-System anderslautend sein kann.
Hierzu wird kurz später in dem Thread eingegangen:
Your volume may not be vg1. Use 'ls -d' to show the correct name eg. . .
nas-3> ls -d /dev/vg*
/dev/vg1000 /dev/vga_arbiter
So you would use the volume group vg1000
fsck.ext4 -pvf /dev/vg1000/lv

Bei mir (mit installierter DSM Version 5.2-5592) lautete der Name "vg1000"

Nachdem ich also 2x einen Check mit anschließendem Reboot habe durchlaufen lassen und heute morgen 5TB auf das erweiterte Volume kopiert habe und keine Fehlermeldungen bezüglich Dateiproblemen von der DS kamen, gehe ich davon aus, das es geholfen hat.

Hier noch das Log, das während des Scans aufgenommen wurde.
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Danke für die detaillierte Beschreibung. *bookmarked*
 

rumknapser

Benutzer
Mitglied seit
02. Mai 2013
Beiträge
329
Punkte für Reaktionen
6
Punkte
24
Gerne, Ihr helft ja auch, wo es nur geht ;-)

Leider werden allerdings ein paar Screenshots nicht angezeigt, die in der Threadvorschau noch vorhanden waren. Ergebnis ist ein Fehler-Link, wenn man draufklickt. Schade. Wenn ich versuche neue Screenshots hochzuladen, geschieht nix. Vllt hab ich ja mein Filelimit erreicht? Egal. Ihr bekommt das schon hin ;-)
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Stimmt, ich sehe die Stelle. Das ist ja seltsam. Ist 'ne normale jpg-Datei, die nicht zu groß ist?
 

rumknapser

Benutzer
Mitglied seit
02. Mai 2013
Beiträge
329
Punkte für Reaktionen
6
Punkte
24
PNG Dateien, die beiden, die Probleme bereiten, sind(sollten) kleiner (Maße/Dateigröße) als die anderen sein und wurden auch in der Threadvorschau passend angezeigt.

Vermutung: Nachdem ich das ganz unten verlinkte LOG als CODE in meinen noch nicht gespeicherten Post eingefügt habe und mir die Forumsoftware dann mitteilte, das der gesamte Text nun zu lang ist und ich ihn doch bitte auf wenige 100000 Zeilen kürzen soll, sind die Bilder verschwunden.
Ich habe daraufhin den LOG-Text wieder gelöscht und ihn als Pastebin-Datei verlinkt, dabei ist mir das Verschwinden aufgefallen, und ich habe versucht, die fehlerhaften Bilder erneut hochzuladen und zu verlinken. Half nichts, wie ich oben schrieb.

Alles unausgereifter Spökes, der für viel Geld verhökert wird ;->
 

rumknapser

Benutzer
Mitglied seit
02. Mai 2013
Beiträge
329
Punkte für Reaktionen
6
Punkte
24
Hallo nochmal,
ich wollte noch kurz nachtragen, welche Auswirkungen diese Meldungen anzeigen können, wenn man einen manuellen fsck, wie oben beschrieben, ausführt:
Rich (BBCode):
File /Ordner/Ordner/Datei.ext (inode #154872027, mod time Sat Feb  7 14:53:00 2015)
  has 128 multiply-claimed block(s), shared with 1 file(s):
/public/Datei.ext (inode #713949394, mod time Sat May 23 17:05:29 2015)
Clone multiply-claimed blocks? yes
(Datei.ext und Ordner habe ich zensiert. Setzt einfach Eure wichtigsten Ordner-/Dateinamen dafür ein...)

Aus dem Log:
/Ordner/Ordner/Datei.ext und /public/Datei.ext

Hierbei handelt es sich ursprünglich um 2 verschiedene (Größe/Dateinamen/Inhalt) Dateien.
Bei mir war es eine AVI und eine MP3 Datei.
Dass im Log etwas von shared steht, lässt die Vermutung aufkommen, die beiden Dateien teilen sich "physisch" auf der Festplatte ein paar gemeinsame Blöcke (Inhalte). Prinzipiell ja kein schlechtes Ding, wenn es denn auch beabsichtigt ist.
In meinem Fall war dies nicht so und so hörte ich, als ich die MP3 Datei dann prüfend abspielte, einige Zitate/Fragmente/Fetzen aus der AVI Datei ;-)

Das war hier zwar lustig, aber wären es meine Produktivdaten, hätte ich es wohl nicht so lustig gefunden.
Glücklich konnte ich mich auch schätzen, da es nur wenige Dateien waren, die inhaltsmäßig "Fremdinhalte" aufwiesen.

Ich habe die betroffenen Dateien einfach aus dem Backup zurückgespielt. (Nachdem ich einen binären Vergleich der jeweiligen inkosistenten Daten und denen aus dem Backup angestellt hatte, um zu sehen, wie viel da so "falsch" ist. Bei manchen Dateien waren nur nur ein paar Bytes am Stück, bei anderen kamen mehrere "falsche" Fragmente vor.)

OHNE dieses Log hätte ich allerdings niemal eine Änderung bemerkt, denn Dateiattribute, wie Datum (letzte Änderung, etc) hatten sich ja nicht geändert. Alles sah augenscheinlich "normal" aus.

Ich für mich, freue mich, das ich ab und an meine Daten mit denen in dem Backup binär vergleiche um so Änderungen am Dateiinhalt zu erkennen.
Das dauert natürlich meist einige Tage, wenn nicht Wochen (je nach Größe und Geschwindigkeit der Hardware, bzw. des Netzes), aber bei wirklich wichtigen Daten ist es unvermeidlich, meine ich.
Hat man kein inkrementelles Backup und überschreibt man das Backup ständig mit "denselben" Daten, kann es vorkommen, das man dann die defekten Daten gesichtert hat. Das wäre ja blöde, sollte man die Daten mal zurückschrieben müssen....

In diesem Sinne:
Macht regelmäßig inkrementelle Backups! auch, wenn es mal länger dauern sollte. Ihr müsst ja nicht alles von Hand selber schreiben ;-)
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Wie vergleichst Du binär?
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Sehr schön. Ich hatte keine Ahnung, dass der TC eine derartige Funktion unterstützt. Danke!
 

moaebi

Benutzer
Mitglied seit
03. Sep 2015
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
Besten Dank für deine ausführliche Beschreibung. Das hat mir ebenfalls sehr geholfen.

Ich hatte anfangs nur ein Problem. Man soll sich ja bei SSH mit dem root account anmelden. Ich habe mich ein paar mal mit dem user admin und dem admin PW angemeldet, doch dort hatte ich keine Berechtigung, erst als ich mich mit dem user root und dem admin PW angemeldet habe hat alles geklappt.
 

anfänger9999

Benutzer
Mitglied seit
19. Sep 2015
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
Hallo,

habe auch das Problem, dass die Plattengröße nicht Vergrößerer werden kann.
Bekomme folgende Meldung PuTTY / Eingeloggt als root

S211> fsck.ext4 -yvf -C0 /dev/vg1/lv
e2fsck 1.42.6 (21-Sep-2012)
fsck.ext4: No such file or directory while trying to open /dev/vg1/lv
Possibly non-existent device?
S211> syno_poweroff_task -d
S211> vgchange -ay
2 logical volume(s) in volume group "vg1" now active
S211> ls -d /dev/vg*
/dev/vg1 /dev/vga_arbiter
S211> fsck.ext4 -yvf -C0 /dev/vg1/lv
e2fsck 1.42.6 (21-Sep-2012)
fsck.ext4: No such file or directory while trying to open /dev/vg1/lv
Possibly non-existent device?

Kann mir jemand einen Tipp geben?
 

Stoneii

Benutzer
Mitglied seit
20. Dez 2013
Beiträge
52
Punkte für Reaktionen
0
Punkte
6
Hallo Leute also bei mir hat diese Info Super Funktioniert!!!
DANKE!!!!
Die ist Gold Wert!!!!

DiskStation> syno_poweroff_task -d
DiskStation> vgchange -ay
1 logical volume(s) in volume group "vg1001" now active
1 logical volume(s) in volume group "vg1000" now active
DiskStation> 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?
DiskStation> fsck.ext4 -pvf -C0 /dev/vg1000/lv

3279503 inodes used (0.90%, out of 365842432)
12537 non-contiguous files (0.4%)
1154 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 3272440/6433/382/1
2549348077 blocks used (87.11%, out of 2926711808)
0 bad blocks
628 large files

3114094 regular files
157722 directories
0 character device files
0 block device files
0 fifos
478427 links
7678 symbolic links (239 fast symbolic links)
0 sockets
------------
3757921 files
DiskStation> fsck.ext4 -pvf -C0 /dev/vg1000/lv

zwei mal gestartet und Fehler sind weg und Nach Reboot rennt es!
 

Iain123

Benutzer
Mitglied seit
11. Jun 2011
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Wobei man beim Namen "/dev/vg1/lv" des Volumes auf Schwierigkeiten stoßen könnte, weil der Name wohl je nach DS-System anderslautend sein kann.
Hierzu wird kurz später in dem Thread eingegangen:
Your volume may not be vg1. Use 'ls -d' to show the correct name eg. . .
nas-3> ls -d /dev/vg*
/dev/vg1000 /dev/vga_arbiter
So you would use the volume group vg1000
fsck.ext4 -pvf /dev/vg1000/lv

Bei mir (mit installierter DSM Version 5.2-5592) lautete der Name "vg1000"

Bei genau diesem Schritt scheitere ich.
Bei mir ist unter /dev/ nur vga_arbiter vorhanden und weder vg1000 oder vg1 sind zu sehen.

Bevor ich auf diesen Thread gestossen bin, muss ich erwähnen, habe ich mich an den Syno-Support gewendet. Diese haben mir zu einem Komplettreset der Konfiguration und einer Neuinstallation des DSM geraten, was ich auch getan habe.
Das Volumen ist zwar noch bestehend, jedoch finde ich unter /dev/ das Verzeichnis nicht...

Kann mir da eventuell jemand weiterhelfen?

Vielen Dank im Voraus
 

Geniemann

Benutzer
Mitglied seit
18. Okt 2012
Beiträge
192
Punkte für Reaktionen
14
Punkte
18
Hallo,

das scheint genau mein Leidensweg zu sein hier und zuerst dachte ich auch, dass es funktioniert, aber dann leider schon wieder ein Problem:
Durch vgchange -a y wird bei mir nichts gemounted. Das Volume1, was vorher da ist und nach syno_poweroff_task -d weg ist, kommt einfach nicht wieder. Dadurch kann ich es natürlich auch nicht überprüfen. Gibt es noch einen anderen Weg das wieder zu verbinden, um es dann zu überprüfen?


Besten Dank
Andreas
 

Geniemann

Benutzer
Mitglied seit
18. Okt 2012
Beiträge
192
Punkte für Reaktionen
14
Punkte
18
Es wird immer komischer: Gestern hat mir die DS von sich aus "vorgeschlagen" eine Dateisystemprüfung nach einem Neustart durchzuführen, weil es Fehler im Dateisystem gebe. Das habe ich dann auch gemacht und als die Prüfung beendet war kam TROTZDEM die gleiche Fehlermeldung wieder, bei dem Versuch das Volume zu erweitern.

Wenn ich alles lösche und einfach ein komplett neues Raid erstelle, geht da irgendwas verloren, was man vorher nicht sichern kann? Die CloudStation Datenbank oder irgendsowas im "Hintergrund"?


Besten Dank
Andreas
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
5.525
Punkte für Reaktionen
1.360
Punkte
234
Ich hatte auch Probleme und konnte sie mit der hier beschriebenen Vorgehensweise lösen.
Danke an den User Rumknapser für die ausführliche Anleitung.

Mit TC (8.51) bin ich nicht weitergekommen. Damit konnte ich irgendwie nur einzelne Files untersuchen, aber keine kompletten Verzeichnisse mit allen Dateien drin. Vielleicht habe ich die Funktion auch übersehen.
Ich habe es jetzt mit Winmerge probiert. Damit kann ich zwei Verzeichnisse angeben und er vergleicht Datei für Datei.
In der Portable-Version bekommt man es hier: http://portableapps.com/de/apps/utilities/winmerge_portable

vergleichen.jpg
 
Zuletzt bearbeitet:

AgentMax

Benutzer
Mitglied seit
20. Apr 2013
Beiträge
48
Punkte für Reaktionen
0
Punkte
0
Ich versuche gerade den Lösungsweg aus Posting 1 auf meiner DS2413+ und DSM 6.1

Ich bekomme jedoch das hier:
fsck.ext4 -pvf /dev/vg1000/lv
/dev/vg1000/lv is mounted.



WARNING!!! The filesystem is mounted. If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.
 
Zuletzt bearbeitet:

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Da hast Du den dritten vor dem ersten Schritt gemacht. Es fehlt offensichtlich zumindest der Befehl "syno_poweroff_task -d". Die nötigen Schritte findest Du z.B. in Beitrag #12.
 

AgentMax

Benutzer
Mitglied seit
20. Apr 2013
Beiträge
48
Punkte für Reaktionen
0
Punkte
0
Habe ich alles befolgt. Komme auch nicht mehr aufs Webinterface und so:
admin@DiskStation:~$ sudo syno_poweroff_task -d

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:

admin@DiskStation:~$ sudo vgchange -ay
1 logical volume(s) in volume group "vg1001" now active
1 logical volume(s) in volume group "vg1000" now active
admin@DiskStation:~$ fsck.ext4 -pvf /dev/vg1000/lv
/dev/vg1000/lv is mounted.
WARNING!!! The filesystem is mounted. If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.


Do you really want to continue<n>? no
check aborted.
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.710
Punkte für Reaktionen
1.020
Punkte
754
Ah, mit mehr Informationen wird auch gleich Dein Fehler deutlich. Du bist nicht als User root angemeldet, musst also zunächst noch den Befehl

Rich (BBCode):
sudo -i

absetzen, sonst funktionierts nicht. Um weiterzumachen, solltest Du die DS neustarten.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat