Die Platte ist voll und ich kann nichts mehr löschen

Ein neuer Artikel wurde veröffentlicht
  • Google mal nach dem Zusammenhang von Inodes und Speicherplatz bei ext-FS. Das macht es klarer.

    Ja, mein Vorpost war falsch, das hab ich auch schon mitbekommen.


    Tja, ist die Platte nun reif zum Wechseln?

    Das einzige, was mir Laien ins Auge sticht ist die "Maximum mount count: -1"

    Die -1 ändert sich auch nicht nach einem Reboot. Heißt das, es erfolgt garkeine regelmäßige Überprüfung mehr? Oder erfolgt die noch nie, weil ich am Anfang einen Fehler gemacht hatte?

    Das ist das eine Problem, das ich langfristig lösen muss.



    Das für mich im Moment dringernde Problem ist, dass ich nicht auf die Platte schreiben kann. Meine Hoffnung ist ja, wenn ich etwas freien Platz bekomme, dass ich dann wieder etwas dauerhaft löschen kann.

    Jetzt ist ja

    Code
    1. df -hT
    2. Filesystem Type Size Used Avail Use% Mounted on
    3. ...
    4. /dev/sda1 ext4 917G 871G 0 100% /media/masse

    Wenn ich jetzt

    Code
    1. sudo tune2fs -m 4.5 /dev/sda1

    ausführe, müsste ich das dann sofort sehen? Also Avail ungleich 0 ?

    Das würde ich dann als Nächstes ausprobieren.

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Das EXT4 Filesystem ist korrupt.

    Primär solltest Du die Eintragungen ab Zeile 46 loswerden.


    Das max mount count -1 ist schon in Ordnung


    Du kannst jetzt versuchen am ungemountete Device das Filesystem einen automatischen Reparaturversuch durchzuführen. Siehe < man e2fsck>


    Als User root:

    umount /dev/sda1

    e2fsck -pfvtt /dev/sda1

    sync

    dumpe2fs -h /dev/sda1 oder tune2fs -l /dev/sda1



    Servus !

  • Das Kind ist zwar schon in den Brunnen geplumbst, aber für die Zukunft;

    Das Teil kann noch mehr, die man-Page ist halbwegs verständlich.


    MfG


    Jürgen

    Jahrelang wurde gesagt:
    Das geht nicht, das gibt es nicht und das war schon immer so.
    Und dann kam einer, der wußte das nicht, und hat es dann einfach gemacht.

  • Hallo RTFM,


    ich versuche gerade deinen Post #24 abzuarbeiten. Jetzt kommt diese Meldung:

    Code
    1. e2fsck -pfvtt /dev/sda1
    2. /dev/sda1: Inode 3331137 seems to contain garbage.
    3. /dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    4. (i.e., without -a or -p options)

    Sie kam schon wenige Sekunden, nachdem ich den Vorgang gestartet hatte.

    Kann ich das ohne -p wiederholen?

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Nein, nicht manuell starten, und schon gar nicht mit -y.

    Vorher musst Du eine Sicherungskopie des aktuellen Superblocks anlegen.


    Du brauchst dazu auf einem anderen Speichermedium wahrscheinlich mehr als 1 GB durchgehenden Speicherplatz.

    Hast Du einen USB Stick, oder eine andere USB HD bereit ?


    Servus !

  • so auf die Schnelle habe ich einen FAT32 Stick mit ca. 15GB frei. Aber ob da ein 1GB-Block frei ist, weiß ich nicht.


    EDIT:

    hier ist noch ei 8GB-Stick, den könnte ich formatieren. In welches Format?

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Ich habe inzwischen etliche Artikel und Beiträge gelesen, habe aber nichts gefunden, wo beschrieben wird, wie man einen Superblock auf USB-Stick sichern kann.


    Wenn das dann gesichert ist, ist dann der Befehl bei ausgehängter Platte und als Root richtig?

    Code
    1. fsck.ext4 /dev/sda1

    Oder bring ich da wieder was durcheinander? Aber erst mal muss ich den Superblock sichern....

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Hi doc !


    Die Anleitung, wie man den Superblock sichert befindet sich auf *DEINEM* Linux in < man e2image>


    Für e2fsck ist es noch viel zu früh. Du weisst ja noch gar nicht was wann und wo eine e2fsck Frage miz ja, oder nein beantwortet werden soll.

    fsck und fsck.ext4ruft auch nur e2fsck auf.


    Und dann studiere < man debugfs >, da bist Du mehr auf Dich gestell, weil ich kein defektes EXT4 Filesystem parat habe, an dem ich probieren könnte.



    Servus !

  • Hi doc !


    Ich nehme an, dass Du nicht mehr jedesmal sudo eingibst, sondern mit < sudo -i > eine root-Konsole gröffnet hast. Wenn nein, hole das jetzt nach.

    Neben dem root-Terminal kannst Du Dir ein zweites Terminal danebenlegen, für die man-Pages.


    EXT4-Superblock sichern: < man e2image >

    Ich schlage für die Sicherungsdatei den Dateiname e2image vor.

    (root):

    umount /dev/sda1

    e2image /dev/sda1 /.../.../e2image

    sync

    dumpe2fs -ih /.../...e2image #Die Optinen i und h sind in < man dumpe2fs > beschrieben

    Wenn die Sicherungsdatei gelesen werden kann, kann sie auch mit der I - Option von e2image auf die Partition zurückgeschrieben werden.


    Jetzt kannst Du erstmals den gesamten Superblock (also nicht nut den Header -h) gleich von der Sicherung ansehen:

    dumpe2fs -i /.../...e2image [ dumpe2fs /dev/sda1 ]


    und für die Fehlersuche eine Textdate vom gesamten Superblock erstellen, indem Du die Terminalausgabe in eine Datei umleitest.

    dumpe2fs -i /.../...e2image > /.../...e2image.txt [ dumpe2fs /dev/sda1 > /.../...e2image.txt]


    Jetzt blättere die Textdatei durch. Nach dem Header findest Du die iNode Gruppen und Blöcke. Vllt findest Du da eine auffalend abweichend grosse iNode Zahl.



    Servus !

    Wer Linux nicht kennt, hat die Zeit verpennt.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von RTFM ()

  • OK, mit Hilfe von Google und meinem analogen Uraltwörterbuch würde ich es vielleicht so machen:


    Die Platte an /dev/sda1 ist ausgehäng, der frisch ext4-formatierte 8GB-USB-Stick ist an /dev/sdb1 eingehängt.

    Code
    1. sudo -i
    2. blkid -o list -w /dev/null
    3. /dev/sda1 ext4 (not mounted) 8505679b-6f31-45c2-a37a-9cd74b7..
    4. /dev/sdb1 ext4 ext4-stick /media/usbstick 225b1094-9c82-4d3f-951d-fd8e189..
    5. e2image -a /dev/sda1 /dev/sdb1/abbild
    6. sync

    Ich frage lieber nach, weil das ist für mich eine OP am offenen Herzen und ich nur _glaube_, zu wissen, was ich mache


    EDIT:

    Tschuldigung, ich hatte den Text begonnen, bevor du deinen letzten Beitrag gesendet hattest. Ich wurde dann gestört, deshalb hat das bei mir so lange gedauert.

    Ich liege also nicht sehr falsch, nur der Parameter -a soll weg. Sonst OK?

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Code
    1. e2image /dev/sda1 /media/usbstick/e2image
    2. e2image 1.43.3 (04-Sep-2016)
    3. e2image: Value too large for defined data type while writing inode table

    Ist der Stick zu klein?

    /dev/sdb1 ext4 7.0G 188M 6.5G 3% /media/usbstick

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Und jetzt wird es interessant.

    Da EXT4 nicht nur einen Superblock hat, sondern einen in Reserve (alternativer Superblock), der noch ein vollkommen funktionierendes Filesystem enthalten sollte, solltest Du jetzt den alternativen Superblock - vorerst nur den Header - ansehen. Bei einer Blockgrösse von 4096 Bytes beginnt der alt. Superblock normalerweise ab Sektor 32768 (siehe man e2fsck).


    dumpe2fs -h -o superblock=32768 /dev/sda1 #zeigt dessen Header - hoffentlich ohne Errormeldungen

    dumpe2fs -f -o superblock=32768 /dev/sda1 > /media/usbstick/e2altimage.txt #speichert den lesbaren Superblock ab, freier Speicherplatz vorrausgesetzt


    Zwischenzeitig heb ich aus Deinen Posts zu Fehlersuche Deine Superblock Ausgaben für die weitere Fehlersuche mit Punkten verdeutlicht und zusammengefasst:


    Filesystem created: Tue Nov 17 15:16:31 2015

    First error time: Fri Dec 18 12:54:48 2015


    Inode count: 61.054.976

    Free inodes: 59.717.973


    First error inode #: 7.995.954

    Last error inode #: 37.355.972


    First error block #: 0

    Last error block #: 149.430.755


    /dev/sda1: Inode 3.331.137 seems to contain garbage.(von e2fsck)


    Fällt Dir was auf ?

    Servus !

  • Code
    1. e2image /dev/sda1 /media/usbstick/e2image
    2. e2image 1.43.3 (04-Sep-2016)
    3. e2image: Value too large for defined data type while writing inode table

    Ist der Stick zu klein?

    Nein, scheint mir nicht. Eine inode (Ganz-)Zahl scheint zu groß zu sein, zumindest grösser als (Inode count:) 61054976

    Aber Du kannst ja auch den 16 Mb Stick mit FAT32 versuchen.

  • Vielen Dank bis hierher.

    Ich muss nun erst mal zur Arbeit und werde morgen deine Hinweise abarbeiten.

    D.h., ich kann mich voraussichtlich frühestens morgen Nachmittag wieder melden.

    Viele Grüße
    DocAdams

    1x RaspberryPi Modell B, 1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC

  • Erstmal eine Bemerkung, was auf der Festplatte bisher geschah:


    Das EXT4 Filesystem wurde vor knapp 2 Jahren, bzw. rd. 1 Monat nach Erstellung , am Fri Dec 18 12:54:48 2015 korrupt und konnte der Fehler dutch das automatische fsck beim Hochfahren nicht repariert werden. Weil die Fehlerbehandlung ( Errors behavior: Continue ) ein Weiterbeschreiben des Filesystems erkaubt, wurde zumindest bei jedem Reboot (bisher rd.370 mal) eine Fehlermeldung an den Sysadmin ins Logfile gelegt. Es können auch > 670.000 Meldungen erfolgt sein, wenn der Level der Protokollierung entsprechend eingestellt ist. Jedenfalls wurden > 670.000 Lese- Schreib- und Löschbefehle fehlerhaft, weil im Binärbaum, der den Filenamen einen inode zuweist, ein Zweig seine Verlinkung verloren hat und bei jedem Schreibzugriff auf den Dateibaum, der beim Anlegen oder Löschen einer Datei erfolgt, nur ein provisorisch aktueller, mit dem bestehenden Fehler erstellt wurde, die alten Systemdaten jedoch als temporäre Systemdateilopien (bis zur Fehlerbehebung duch den Sysadmin ) im Dateisystem liegenblieben und nunmehr alle Inodes verbraucht haben.


    Da auch fschk = e2fsck Plattenplatz (Und freie inides) braucht (5% sind noch vorhanden) wäre das unkontrollierte -t Löschen ganzer Verzeichnisse zu unterlassen, weil dies vor Behebung des Dateisystemfehlers nur zu einem weiteren Plattenplatzverbrauch für weitere temporäre Systemkopien von EXT4 Verwaltungsdaten führt.



    Servus !


    PS: Wenn einem EXT4 superuser kein Plattenplatz reserviert werden soll, oder wird, dann sollte das Error Behavior gleichzeitig umgestellt werden, damit im Fehlerfall das Dateisystem nur mehr read-only z.V. steht.