fsck abbrechen?

21/09/2012 - 11:11 von Rainer H. Rauschenberg | Report spam
Hallo,

ich habe auf einer Slug (NSLU2) mit Debian Squeeze ein fsck auf einer
USB-Festplatte (1 TB) laufen. Da das Geràt nur 32 MB Ram und 266 MHz
hat, zieht sich das ganze ... seit etwa 2 Tagen keine neuen
Bildschirmausgaben (làuft in einer screen-Session). Es wurden bereits
Fehler berichtet, iotop zeigt auch Schreibzugriffe, top sagt, daß
fsck.ext3 konstant über 90% CPU-Last und reichlich (naja, 175 MB)
virtuellen Speicher beansprucht. Ich vermute, daß das ganze u.a. wegen
des notwendigen Geswappes so lange dauert.

Meine Frage: Wie hoch ist das Risiko, daß bei einem Abbruch von fsck
mehr kaputt geht bzw. im Endeffekt weniger zu reparieren ist als wenn
ich es laufen lasse? Und falls Abbruch eine sinnvolle Option ist: Wie
macht man das am höflichsten? Ctrl-C, kill, oder wie?

letzte Bildschirmausgabe war (Einrückung manipuliert, um Zeile nicht
noch breiter werden zu lassen)

schnipp
Durchgang 1C: Prüfe Verzeichnisse nach Inodes mit doppelten Blocks.
Durchgang 1D: Gleiche doppelte Blocks ab
(es gibt 24 Inodes, die doppelte/defekte Blocks enthalten.)

Datei ... (Inode #4120577, mod time Tue Jul 3 20:07:28 2012)
hat 24425 doppelte Block(s), geteilt mit 1 Datei(en):
/fM-CM-<rallefilme/alphacentauri/alpha-centauri-marsgesicht-1998_x100.mp4
(Inode #54452225, mod time Tue Jul 3 20:07:28 2012)
multiply claimed block map<j>? ja
schnapp

Sinn des beabsichtigten Abbruchs ist, das Ganze nochmal an einem etwas
großzügiger ausgestatteten Rechner zu starten.

Rainer "TIA" Rauschenberg
 

Lesen sie die antworten

#1 Marcel Müller
21/09/2012 - 17:05 | Warnen spam
Hallo,

On 21.09.2012 11:11, Rainer H. Rauschenberg wrote:
ich habe auf einer Slug (NSLU2) mit Debian Squeeze ein fsck auf einer
USB-Festplatte (1 TB) laufen. Da das Geràt nur 32 MB Ram und 266 MHz
hat, zieht sich das ganze ... seit etwa 2 Tagen keine neuen
Bildschirmausgaben (làuft in einer screen-Session). Es wurden bereits
Fehler berichtet, iotop zeigt auch Schreibzugriffe, top sagt, daß
fsck.ext3 konstant über 90% CPU-Last und reichlich (naja, 175 MB)
virtuellen Speicher beansprucht. Ich vermute, daß das ganze u.a. wegen
des notwendigen Geswappes so lange dauert.



bei 90% CPU swappt so gut wie nichts. Wàhrend er auf Swap wartet, wàre
die CPU Last bei 0%. Wàre das hàufig der Fall, wàre die Gesamtlast niedrig.

Gefühlt würde ich sagen, dass das Dateisystem einen Fehler hat, mit dem
fschk nicht klar kommt (Endlosschleife). Ich meine ext3 ist doch ein
Dateisystem mit Journal. Da ist der Check doch normalerweise eher
schnell. ext2 war doch die Katastrophe bei großen Volumes, oder?

Oder hat das Dateisystem Myriaden von kleinen Inodes? Das macht die
Checks auch lahm.


Meine Frage: Wie hoch ist das Risiko, daß bei einem Abbruch von fsck
mehr kaputt geht bzw. im Endeffekt weniger zu reparieren ist als wenn
ich es laufen lasse?



AFAIK gering. Die meisten File-System-Checker arbeiten weitgehend
transaktional. Also erst mal alle Änderungen im RAM sammeln und zum
Schluss gesammelt auf die Disk damit. Es werden bei einem FS-Check ja
sowieso nur Metadaten geschrieben.

Ob es jetzt ext3 genauso macht, ist eine andere Sache. Das habe ich nie
benutzt, nur xfs, jfs, hpfs und mittlerweile ext4. Letzteres ist aber
auch etwas lahm bei den Checks.

Und falls Abbruch eine sinnvolle Option ist: Wie
macht man das am höflichsten? Ctrl-C, kill, oder wie?



Dürfte egal sein.


letzte Bildschirmausgabe war (Einrückung manipuliert, um Zeile nicht
noch breiter werden zu lassen)

schnipp
Durchgang 1C: Prüfe Verzeichnisse nach Inodes mit doppelten Blocks.
Durchgang 1D: Gleiche doppelte Blocks ab
(es gibt 24 Inodes, die doppelte/defekte Blocks enthalten.)

Datei ... (Inode #4120577, mod time Tue Jul 3 20:07:28 2012)
hat 24425 doppelte Block(s), geteilt mit 1 Datei(en):
/fM-CM-<rallefilme/alphacentauri/alpha-centauri-marsgesicht-1998_x100.mp4
(Inode #54452225, mod time Tue Jul 3 20:07:28 2012)
multiply claimed block map<j>? ja
schnapp



Bei derartigen Inkonsistenzen ist das Backup die bessere Wahl. Bei
solchen Fehlern weiß man nie, ob nicht etliche, vermeintlich
unbeschàdigte Dateien doch latent kaputt sind und dann die noch intakten
Versionen des Backups nach und nach ersetzen.
Also Backup nehmen, und nur einzelne, neuere Dateien aus der defekten
Platte lesen, falls noch da.

Etwas abrücken würde ich von meiner Aussage, falls es sich bei den
betroffenen Dateien nur genau um jene handelt, die just vor dem Moment,
da die Kiste seinerzeit abgesemmelt ist, geschrieben oder gelöscht
wurden. Dann ist es zumindest wahrscheinlich, dass àltere Datenbestànde
nicht in größerem Umfang betroffen sind.

Sinn des beabsichtigten Abbruchs ist, das Ganze nochmal an einem etwas
großzügiger ausgestatteten Rechner zu starten.



Mach das.


Marcel

Ähnliche fragen