Fehler im Dateisystem erkannt.

[seekwest]

 

[dil88]

Die Liste ist nicht komplett.

 

[seekwest]

aktuell "hängt" dort die Ausgabe, wie man auch am Cursor sieht, bisher (ca. 5 Mins) kamen noch keine
weiteren Daten hinzu. Woran könnte das liegen?

 

[Frogman]

Woran? Naja, die Datensystemfehler sind da schon hauptverdächtig...

 

[dil88]

Mach bitte in einer neuen Shell ein

ls -al /

Ansonsten hat Frogman ja schon auf Probleme mit den Platten und dem Filesystem hingewiesen.

 

[goetz]

Hallo,
ohne den Parameter x wird auch volume1 komplett durchgezählt, bei 5TB Daten dauert das entsprechend.

Gruß Götz

 

[seekwest]

goetz hat Recht, Anfrage hat ne kleine Ewigkeit gedauert, hier nun
der komplette Screenshot:



und nun auch: ls -al /

 

[dil88]

Sorry, bringt leider auch keine neuen Erkenntnisse, das Inhaltsverzeichnis ebenfalls nicht. Zur Bereinigung des Filesystems hilft Dir vielleicht dieser Beitrag weiter.

 

[seekwest]

Den habe ich mir schon angeschaut:

Allerdings wird mit mit: ls -d /dev/vg*
nur /dev/vga_arbiter angezeigt, kein weiteres Volumen.

df zeigt mir für volume1: /dev/mapper/vol1-origin

Nach:
syno_poweroff_task -d

kann ich jedoch kein check durchführen, da
/dev/mapper/vol1-origin

dann "weg" ist. leider bekomme ich auch IPKG nicht installiert, sonst könnte ich
mit LSOF die Dienste einzeln stoppen ohne "syno_poweroff_task -d" auszuführen.

Gabs das Problem bisher auch schon?
Ich hab mit der Suche nichts gefunden.

 

[dil88]

Ich habe mir, bevor ich den Link gepostet habe, nochmal Deine Postings auf der ersten Seite angeschaut. Da verwendest Du andere devices. Den Hintergrund hast Du zwar gerade erklät, ich würde es aber nochmal genau mit den Aufrufen probieren, die in dem von mir verlinkten Posting zum Erfolg geführt haben. Wenn auch das nichts bringt, solltest Du Dich an Synology wenden.

 

[seekwest]

ist eigentlich das gleiche device:



prüfen kann ich es trotzdem nicht. Was könnte ich noch testen?

 

[dil88]

Einerseits gehts ja auch um /dev/root. Andererseits: Was bekommst Du denn mit ls -d angezeigt?

 

[seekwest]

 

[dil88]

Du hast ja von Anfang an alles nach der Vorlage gemacht, die Du auch selbst im Initial-Post verlinkt hast. Habe mir jetzt alles nochmal angeschaut und mit meiner DS abgeglichen. Ohne kompletten Überblick steige zumindest ich hier nicht mehr durch und schreibe leider Unfug, sorry.

Zwei Dinge könntest Du m.E. noch tun: Schau Dir per

ls -al /var/log

an, ob es dort ein großes, entbehrliches Logfile gibt. Ggfs. ziehst Du es Dir vorher mit WinSCP auf den Rechner und löschst es dann per

cat /dev/null > /var/log/<Logfile>

<Logfile> musst Du durch den gewünschten Dateinamen ersetzen. Wenn Du auf die Weise genug Platz geschaffen hast, um wieder ins DSM-Webfrontend zu kommen, könntest Du dort noch einmal schauen, ob das System etwas anbietet.

Ansonsten könnte ein Superblock defekt sein, wie es im Output steht, den Du in Beitrag 6 gepostet hast. Dann wäre das dort vorgeschlagene Kommando eine Option, um eine andere Kopie des Superblocks zu verwenden.

 

[seekwest]

Ich hab jetzt einige Logfiles gelöscht. Kann mich also wieder im
DSM anmelden. Aus dem Hilfe-Thread welchen ich gepostet hatte,
habe ich entnommen, dass das Problem bei einem User auch behoben wurde,
als er das RAID durch entfernen einer Festplatte dannach rebuildete.

Das hab ich jetzt auch gemacht, der Reparaturvorgang wurde abgeschlossen.
Allerdings hat sich dadurch das Problem nicht behoben:



Habt ihr noch eine Empfehlung was ich mal testen kann?

 

[seekwest]

Wie kann ich denn einen defekten Superblock reparieren?
Über die Anleitung, die ich gepostet hatte, funktioniert es ja nicht.

Sollte ich dann die rabiate Methode nutzen?
DS runterfahren, Disk 1 entfernen, booten, herunterfahren, wieder einstecken, RAID reparieren
und das dann nach und nach mit allen 4 Festplatten machen, oder wie wäre dann der richtige Weg?