tune2fs -l /dev/sdxp
ist aber wesentlich genauer
Bei einem used-ratio von 3% sowas von egal
tune2fs -l /dev/sdxp
ist aber wesentlich genauer
Bei einem used-ratio von 3% sowas von egal
Die Platte ist voll und ich kann nichts mehr löschen? Schau mal ob du hier fündig wirst!
Mir wäre das nicht egal, ich würde die Ursache ergünden wollen.
Die Platte ist keineswegs schrottreif, wie der TO das befürchtet.
Servus !
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.
sudo tune2fs -l /dev/sda1
tune2fs 1.43.3 (04-Sep-2016)
Filesystem volume name: <none>
Last mounted on: /media/masse
Filesystem UUID: 8505679b-6f31-45c2-a37a-9cd74b777f44
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244190390
Reserved block count: 12209519
Free blocks: 12213615
Free inodes: 59717973
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Nov 17 15:16:31 2015
Last mount time: Mon Nov 27 11:01:15 2017
Last write time: Mon Nov 27 11:01:15 2017
Mount count: 374
Maximum mount count: -1
Last checked: Tue Nov 17 15:16:31 2015
Check interval: 0 (<none>)
Lifetime writes: 1313 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 060614a7-cd41-4a4e-8e4d-b7b6bbec66a6
Journal backup: inode blocks
FS Error count: 692054
First error time: Fri Dec 18 12:54:48 2015
First error function: ext4_lookup
First error line #: 1588
First error inode #: 7995954
First error block #: 0
Last error time: Sun Nov 26 19:20:07 2017
Last error function: htree_dirblock_to_tree
Last error line #: 1000
Last error inode #: 37355972
Last error block #: 149430755
Alles anzeigen
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
df -hT
Filesystem Type Size Used Avail Use% Mounted on
...
/dev/sda1 ext4 917G 871G 0 100% /media/masse
Wenn ich jetzt
ausführe, müsste ich das dann sofort sehen? Also Avail ungleich 0 ?
Das würde ich dann als Nächstes ausprobieren.
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>
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;
sudo apt install di
di -f siUF
Filesystem Inodes IUsed IFree
/dev/root 948192 118300 829892
/dev/mmcblk0p1 0 0 0
tmpfs 110069 1 110068
tmpfs 110069 523 109546
tmpfs 110069 7 110062
tmpfs 110069 4 110065
tmpfs 110069 10 110059
/dev/sda1 30531584 20129 30511455
Alles anzeigen
Das Teil kann noch mehr, die man-Page ist halbwegs verständlich.
MfG
Jürgen
Hallo RTFM,
ich versuche gerade deinen Post #24 abzuarbeiten. Jetzt kommt diese Meldung:
e2fsck -pfvtt /dev/sda1
/dev/sda1: Inode 3331137 seems to contain garbage.
/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Sie kam schon wenige Sekunden, nachdem ich den Vorgang gestartet hatte.
Kann ich das ohne -p wiederholen?
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?
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?
8 GB - Ext4 würde reichen, hoffentlich.
Servus !
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?
Oder bring ich da wieder was durcheinander? Aber erst mal muss ich den Superblock sichern....
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 !
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.
sudo -i
blkid -o list -w /dev/null
/dev/sda1 ext4 (not mounted) 8505679b-6f31-45c2-a37a-9cd74b7..
/dev/sdb1 ext4 ext4-stick /media/usbstick 225b1094-9c82-4d3f-951d-fd8e189..
e2image -a /dev/sda1 /dev/sdb1/abbild
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?
e2image /dev/sda1 /media/usbstick/abbild
oder
e2image /dev/sda1 /media/usbstick/e2image
Servus !
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 !
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.
Wenn Du kein Sicherungsfile erstellen kannst. mach halt ohne weiter. Ich habe dafür [text] im Beitrag oben angelegt.
Vielleicht findest Du schon in den Gruooen 0 - 10 im Text einen auffälligen Fehlrthinweis.
Servus !.
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.
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.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!