Ich habe diese externe USB-Platte:
kaefert@blechmobil:~$ lsusb -s 2:3
Bus 002 Device 003: ID 0bc2:3320 Seagate RSS LLC
Wie aus der folgenden Dmesg-Ausgabe hervorgeht, gibt es ein Problem, das das Mounten der Festplatte verhindert:
kaefert@blechmobil:~$ dmesg
...
[ 113.084079] usb 2-1: new high-speed USB device number 3 using ehci_hcd
[ 113.217783] usb 2-1: New USB device found, idVendor=0bc2, idProduct=3320
[ 113.217787] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 113.217790] usb 2-1: Product: Expansion Desk
[ 113.217792] usb 2-1: Manufacturer: Seagate
[ 113.217794] usb 2-1: SerialNumber: NA4J4N6K
[ 113.435404] usbcore: registered new interface driver uas
[ 113.455315] Initializing USB Mass Storage driver...
[ 113.468051] scsi5 : usb-storage 2-1:1.0
[ 113.468180] usbcore: registered new interface driver usb-storage
[ 113.468182] USB Mass Storage support registered.
[ 114.473105] scsi 5:0:0:0: Direct-Access Seagate Expansion Desk 070B PQ: 0 ANSI: 6
[ 114.474342] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 114.475089] sd 5:0:0:0: [sdb] Write Protect is off
[ 114.475092] sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 114.475959] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 114.477093] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 114.501649] sdb: sdb1
[ 114.502717] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 114.504354] sd 5:0:0:0: [sdb] Attached SCSI disk
[ 116.804408] EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 3976 failed (47397!=61519)
[ 116.804413] EXT4-fs (sdb1): group descriptors corrupted!
...
Also habe ich meinen Lieblingspartitionsmanager - gparted - gestartet und ihn angewiesen, die Partition sdb1 zu überprüfen und zu reparieren. Daraufhin hat gparted e2fsck aufgerufen (Version 1.42.4 (12. Juni 2012)).
e2fsck -f -y -v /dev/sdb1
Obwohl gparted e2fsck mit der Option "-v" aufgerufen hat, zeigt es mir leider nicht die Ausgabe meines e2fsck-Prozesses an (bugreporthttps://bugzilla.gnome.org/show_bug.cgi?id=467925)
Ich habe mit der ganzen Sache am Sonntagabend (2012-11-04_22:00) angefangen, also vor ungefähr 48 Stunden. Das hier sagt htop jetzt (2012-11-06-19:00) dazu:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
3704 root 39 19 1560M 1166M 768 R 98.0 19.5 42h56:43 e2fsck -f -y -v /dev/sdb1
Jetzt habe ich im Internet einige Beiträge gefunden, in denen es um die langsame Ausführung von e2fsck geht, zum Beispiel:
http://gparted-forum.surf4.info/viewtopic.php?id=13613
Dort steht, dass es eine gute Idee ist, zu prüfen, ob die Festplatte nur deshalb so langsam ist, weil sie vielleicht beschädigt ist. Ich denke, diese Ausgaben sagen mir, dass dies in meinem Fall nicht der Fall ist:
kaefert@blechmobil:~$ sudo hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 3562 MB in 2.00 seconds = 1783.29 MB/sec
Timing buffered disk reads: 82 MB in 3.01 seconds = 27.26 MB/sec
kaefert@blechmobil:~$ sudo hdparm /dev/sdb
/dev/sdb:
multcount = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 364801/255/63, sectors = 5860533160, start = 0
Obwohl ich schnell von dieser Festplatte lesen kann, scheint diese Festplattengeschwindigkeit von e2fsck nicht genutzt zu werden, wenn man Tools wie gkrellm oder iotop oder das hier berücksichtigt:
kaefert@blechmobil:~$ iostat -x
Linux 3.2.0-2-amd64 (blechmobil) 2012-11-06 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
14,24 47,81 14,63 0,95 0,00 22,37
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,59 8,29 2,42 5,14 43,17 160,17 53,75 0,30 39,80 8,72 54,42 3,95 2,99
sdb 137,54 5,48 9,23 0,20 587,07 22,73 129,35 0,07 7,70 7,51 16,18 2,17 2,04
Jetzt habe ich ein bisschen recherchiert, wie ich herausfinden kann, was e2fsck mit der ganzen Prozessorzeit macht, und bin auf das Tool strace gestoßen, das mir Folgendes liefert:
kaefert@blechmobil:~$ sudo strace -p3704
lseek(4, 41026998272, SEEK_SET) = 41026998272
write(4, "\212\354K[_\361\3nl\212\245\352\255jR\303\354\312Yv\334p\253r\217\265\3567\325\257\3766"..., 4096) = 4096
lseek(4, 48404766720, SEEK_SET) = 48404766720
read(4, "\7t\260\366\346\337\304\210\33\267j\35\377'\31f\372\252\ffU\317.y\211\360\36\240c\30`\34"..., 4096) = 4096
lseek(4, 41027002368, SEEK_SET) = 41027002368
write(4, "\232]7Ws\321\352\t\1@[+5\263\334\276{\343zZx\352\21\316`1\271[\202\350R`"..., 4096) = 4096
lseek(4, 48404770816, SEEK_SET) = 48404770816
read(4, "\17\362r\230\327\25\346//\210H\v\311\3237\323K\304\306\361a\223\311\324\272?\213\tq \370\24"..., 4096) = 4096
lseek(4, 41027006464, SEEK_SET) = 41027006464
write(4, "\367yy>x\216?=\324Z\305\351\376&\25\244\210\271\22\306}\276\237\370(\214\205G\262\360\257#"..., 4096) = 4096
lseek(4, 48404774912, SEEK_SET) = 48404774912
read(4, "\365\25\0\21|T\0\21}3t_\272\373\222k\r\177\303\1\201\261\221$\261B\232\3142\21U\316"..., 4096) = 4096
^CProcess 3704 detached
etwa 16 solcher Zeilen pro Sekunde, also 4 Lese- und 4 Schreibvorgänge pro Sekunde, was ich nicht für viel halte.
Und zum Schluss meine Frage: Wird dieser Vorgang jemals abgeschlossen? Wenn die Zahlen von fseek (48404774912) Bytes darstellen, wären das etwa 45 Gigabyte, wobei es sich um eine 3-Terabyte-Festplatte handelt, was mir 134 Tage Zeit geben würde, wenn die Geschwindigkeit konstant bleibt und e2fsck die Festplatte auf diese Weise vollständig und nur einmal scannt.
Haben Sie einen Rat für mich? Die meisten Daten auf dieser Platte sind woanders, aber ich habe viele Stunden damit verbracht, sie zu sortieren und auf dieser Platte zusammenzuführen. Daher würde ich diese Platte lieber wieder zum Laufen bringen, ohne sie neu zu formatieren. Ich glaube nicht, dass die Hardware beschädigt ist, da die Platte erst ein paar Monate alt ist und ich in der dmesg-Ausgabe keine E/A-Fehler sehe.
AKTUALISIEREN:Habe mir gerade nochmal die Strace-Ausgabe angeschaut (2012-11-06_2300), jetzt sieht sie so aus:
lseek(4, 1419860611072, SEEK_SET) = 1419860611072
read(4, "3#\f\2447\335\0\22A\355\374\276j\204'\207|\217V|\23\245[\7VP\251\242\276\207\317:"..., 4096) = 4096
lseek(4, 43018145792, SEEK_SET) = 43018145792
write(4, "]\206\231\342Y\204-2I\362\242\344\6R\205\361\324\177\265\317C\334V\324\260\334\275t=\10F."..., 4096) = 4096
lseek(4, 1419860615168, SEEK_SET) = 1419860615168
read(4, "\262\305\314Y\367\37x\326\245\226\226\320N\333$s\34\204\311\222\7\315\236\336\300TK\337\264\236\211n"..., 4096) = 4096
lseek(4, 43018149888, SEEK_SET) = 43018149888
write(4, "\271\224m\311\224\25!I\376\16;\377\0\223H\25Yd\201Y\342\r\203\271\24eG<\202{\373V"..., 4096) = 4096
lseek(4, 1419860619264, SEEK_SET) = 1419860619264
read(4, ";d\360\177\n\346\253\210\222|\250\352T\335M\33\260\320\261\7g\222P\344H?t\240\20\2548\310"..., 4096) = 4096
lseek(4, 43018153984, SEEK_SET) = 43018153984
write(4, "\360\252j\317\310\251G\227\335{\214`\341\267\31Y\202\360\v\374\307oq\3063\217Z\223\313\36D\211"..., 4096) = 4096
Daher sind die Zahlen in den LSeek-Zeilen vor den Lesevorgängen, beispielsweise 1419860619264, bereits wesentlich größer und entsprechen 1,29 Terabyte, wenn diese Zahlen in Bytes ausgedrückt werden. Es scheint sich also nicht um einen linearen Fortschritt im großen Maßstab zu handeln. Vielleicht gibt es nur einige Bereiche, die Arbeit erfordern und zwischen denen große Lücken bestehen.
UPDATE2:Okey, große Enttäuschung, die Zahlen sind wieder sehr klein (2012-11-07_0720)
lseek(4, 52174548992, SEEK_SET) = 52174548992
read(4, "\374\312\22\\\325\215\213\23\0357U\222\246\370v^f(\312|f\212\362\343\375\373\342\4\204mU6"..., 4096) = 4096
lseek(4, 46603526144, SEEK_SET) = 46603526144
write(4, "\370\261\223\227\23?\4\4\217\264\320_Am\246CQ\313^\203U\253\274\204\277\2564n\227\177\267\343"..., 4096) = 4096
also geht e2fsck die Daten entweder mehrmals durch oder springt einfach mehrmals hin und her. Oder meine Annahme, dass es sich bei diesen Zahlen um Bytes handelt, ist falsch.
UPDATE3:Da es hier erwähnt wird
http://forums.fedoraforum.org/showthread.php?t=282125&page=2
dass Sie testisk ausführen können, während e2fsck läuft. Ich habe das versucht, allerdings nicht mit großem Erfolg. Wenn ich testdisk auffordere, die Daten meiner Partition anzuzeigen, erhalte ich Folgendes:
TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
1 P Linux 0 4 5 45600 40 8 732566272
Can't open filesystem. Filesystem seems damaged.
Und das ist, was Strace mir derzeit gibt (2012-11-07_1030)
lseek(4, 212460343296, SEEK_SET) = 212460343296
read(4, "\315Mb\265v\377Gn \24\f\205EHh\2349~\330\273\203\3375\206\10\r3=W\210\372\352"..., 4096) = 4096
lseek(4, 47347830784, SEEK_SET) = 47347830784
write(4, "]\204\223\300I\357\4\26\33+\243\312G\230\250\371*m2U\t_\215\265J \252\342Pm\360D"..., 4096) = 4096
UPDATE4:(08.11.2012_0800) Okay, also der e2fsk-Prozess ist nach etwas über 78 Stunden fehlgeschlagen (das hat gparted geschrieben) und als ich versucht habe, gparted dazu zu bringen, die Details zu speichern, hat es nicht mehr reagiert, für ein paar Minuten 100 % der CPU-Zeit eines meiner Kerne beansprucht und ist dann abgestürzt und hat diese Zeile in der Konsole ausgegeben:
/usr/sbin/gpartedbin: symbol lookup error: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: undefined symbol: g_mutex_lock
Es stürzte ab, bevor ich einen Speicherort für die Details auswählen konnte, also begann es nicht einmal, diese Details in eine Datei zu schreiben. Ich habe also nichts weiter als einen kurzen Blick auf etwa 5 Zeilen der e2fsck-Ausgabe erhascht, in denen etwas über beschädigte Inodes stand, die repariert wurden. Ich vermute, dass die Ausgabe von e2fsck so extrem lang war, dass gparted sie nicht verarbeiten konnte und beim Versuch abstürzte.
Dies ist die Strace-Ausgabe des gparted-bin-Prozesses in seiner letzten Laufzeit bis zu seinem Ausfall:
http://pastebin.ubuntu.com/1341922/
Jetzt habe ich mein Notebook neugestartet und war positiv überrascht, Folgendes zu sehen:
[ 1.368032] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[ 1.501581] usb 2-1: New USB device found, idVendor=0bc2, idProduct=3320
[ 1.501585] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1.501588] usb 2-1: Product: Expansion Desk
[ 1.501590] usb 2-1: Manufacturer: Seagate
[ 1.501592] usb 2-1: SerialNumber: NA4J4N6K
[ 1.503691] usbcore: registered new interface driver uas
[ 1.504736] Initializing USB Mass Storage driver...
[ 1.504822] scsi5 : usb-storage 2-1:1.0
[ 1.504898] usbcore: registered new interface driver usb-storage
[ 1.504900] USB Mass Storage support registered.
...
[ 2.504756] scsi 5:0:0:0: Direct-Access Seagate Expansion Desk 070B PQ: 0 ANSI: 6
...
[ 13.319905] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 13.320764] sd 5:0:0:0: [sdb] Write Protect is off
[ 13.320768] sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 13.321644] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 13.322524] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 19.563252] sdb: sdb1
[ 19.564818] sd 5:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
[ 19.566944] sd 5:0:0:0: [sdb] Attached SCSI disk
...
[ 105.080095] EXT4-fs (sdb1): warning: mounting unchecked fs, running e2fsck is recommended
[ 105.086041] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Er konnte das Dateisystem also erneut mounten und auf den ersten Blick sah es auch ganz gut aus. Aber wie in der obigen dmesg-Ausgabe empfohlen, startete ich e2fsck erneut, dieses Mal jedoch manuell ohne gparted als Vermittler:
kaefert@blechmobil:~$ sudo e2fsck -v -p /dev/sdb1
/dev/sdb1 wurde nicht ordnungsgemäß ausgehängt, Prüfung erzwungen.
/dev/sdb1: Doppelter oder unzulässiger Block in Gebrauch!
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294954142 for Den Eintrag in der Liste belegter Blöcke verdoppeln
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294960577 for Den Eintrag in der Liste belegter Blöcke verdoppeln
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294902002 for Den Eintrag in der Liste belegter Blöcke verdoppeln
/dev/sdb1: Mehrfach beansprucht Block(s) in Inode 86114492: 4538368 3365377 3365378 3365379 3365380 ...
... << endless number of inodes, like millions of inodes, didn't count them though ;) >> ...
55455 9455456 9455457 9455458 9455459 << this is the end of the list >>
/dev/sdb1: (es gibt 6 Inodes, die doppelte/defekte Blocks enthalten.)
/dev/sdb1: Datei /Recordings/.../MVI_8559.MOV (Inode #86114492, Modifikationszeitpunkt Sat Mar 24 20:23:54 2012)
hat Block Nr.413455 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/dev/sdb1: /Recordings/.../MVI_8563.MOV (Inode #86114496, mod time Sat Mar 24 20:23:54 2012)
/dev/sdb1:
/dev/sdb1: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN
(d.h. ohne -a oder -p Option)
Also werde ich genau das tun und jetzt ohne den Parameter -p beginnen. Da der obige e2fsck-Lauf nur etwa 2 Stunden gedauert hat, werde ich Ihnen in etwa 2 Stunden wohl ein weiteres Update geben.
kaefert@blechmobil:~$ sudo e2fsck -v /dev/sdb1
e2fsck 1.42.4 (12-Jun-2012)
/dev/sdb1 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen.
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Doppelter Blocks gefunden... starte Scan nach doppelten Block.
Durchgang 1B: Suche nach doppelten/defekten Blocks
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294954142 for Den Eintrag in der Liste belegter Blöcke verdoppeln
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294960577 for Den Eintrag in der Liste belegter Blöcke verdoppeln
ext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294902002 for Den Eintrag in der Liste belegter Blöcke verdoppeln
Mehrfach beansprucht Block(s) in Inode 86114492: 4538368 3365377 3365378 3365379 3365380 ... 9455459
Durchgang 1C: Prüfe Verzeichnisse nach Inodes mit doppelten Blocks.
Durchgang 1D: Gleiche doppelte Blocks ab
(es gibt 6 Inodes, die doppelte/defekte Blocks enthalten.)
Datei /Recordings/.../MVI_8559.MOV (Inode #86114492, Modifikationszeitpunkt Sat Mar 24 20:23:54 2012)
hat Block Nr.413455 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8563.MOV (Inode #86114496, mod time Sat Mar 24 20:23:54 2012)
multiply claimed block map<j>? ja
clone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefunden
clone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefunden
Datei /Recordings/.../MVI_8563.MOV (Inode #86114496, Modifikationszeitpunkt Sat Mar 24 20:23:54 2012)
hat Block Nr.413455 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8559.MOV (Inode #86114492, mod time Sat Mar 24 20:23:54 2012)
Duplizierte Blocks bereits neu zugeordnet bzw. geklont.
Datei /Recordings/.../MVI_8571.MOV (Inode #86114504, Modifikationszeitpunkt Sat Mar 24 22:09:56 2012)
hat Block Nr.244958 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8575.MOV (Inode #86114508, mod time Sat Mar 24 22:09:56 2012)
multiply claimed block map<j>? ja
clone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefunden
und jetzt scheint sich das Muster des ersten extrem langen Laufs von e2fsck zu wiederholen. Die Strace-Ausgabe sieht gleich aus und die Gkrellm-Darstellung der Festplattennutzung auch (siehe unten). und seit der letzten Ausgabe, die ich oben gepostet habe, sind ungefähr 2 Stunden vergangen.
UPDATE5:(2012-11-08_2130) Okay, also e2fsck läuft schon wieder seit ungefähr 12 Stunden und davon mindestens 10, seit die letzte Zeile, die ich oben gepostet habe, gedruckt wurde. Ich fürchte, es wird wieder 80 Stunden dauern, bis es fertig ist (oder fehlschlägt), wie beim ersten Mal, als ich dieses Muster gesehen habe.
UPDATE6:(2012-11-09_0653) Ich habe oben in der Konsolenausgabe meines dritten e2fsck-Laufs ein paar neue Zeilen hinzugefügt (er hat eine zweite Frage gestellt, und jetzt sind wir wieder beim Muster, das unter der Ausgabe beschrieben und durch diesen gkrellm-Screenshot visualisiert wird).
UPDATE7:(2012-11-11_1839) Soooo... es ist fertig. Hier sind die letzten Zeilen dessen, was es ausgedruckt hat:
Die Anzahl Verzeichnisse ist falsch für Gruppe #20192 (0, gezählt=1).
Repariere<j>? ja
Die Anzahl freier Inodes ist falsch für Gruppe #20576 (8192, gezählt=8143).
Repariere<j>? ja
Die Anzahl Verzeichnisse ist falsch für Gruppe #20576 (0, gezählt=3).
Repariere<j>? ja
Die Anzahl freier Inodes ist falsch für Gruppe #21472 (8192, gezählt=8182).
Repariere<j>? ja
Die Anzahl Verzeichnisse ist falsch für Gruppe #21472 (0, gezählt=1).
Repariere<j>? ja
Die Anzahl freier Inodes ist falsch (183148563, gezählt=183026594).
Repariere<j>? ja
/dev/sdb1: ***** DATEISYSTEM WURDE VERÄNDERT *****
121950 Inodes sind in Benutzung (0.07%)
1244 nicht zusammenhängende Dateien (1.0%)
30 nicht zusammenhängende Verzeichnisse (0.0%)
# von Inodes mit ind/dind/tind Blöcken: 0/0/0
Erweiterungstiefe Histogramm: 121817/126
184589222 Blöcke werden benutzt (25.20%)
0 ungültige Blöcke
4 große Dateien
119828 reguläre Dateien
2114 Verzeichnisse
0 zeichenorientierte Gerätedateien
0 Blockgerätedateien
0 Fifos
9 Verknüpfungen
0 symbolische Verknüpfungen (0 schnelle symbolische Verknüpfungen)
0 Sockets
--------
121397 Dateien
Um diese Millionen Fragen zu beantworten, musste ich etwas auf den Buchstaben „j“ schreiben.
Und da ich ihm nicht glaubte, dass es jetzt wirklich sauber ist, ließ ich es ein viertes Mal laufen, und e2fsck gab zu, dass nicht alles richtig war, und er ließ sich immer noch Dinge zu tun:
kaefert@blechmobil:~$ sudo e2fsck -f -y -v /dev/sdb1
e2fsck 1.42.4 (12-Jun-2012)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Doppelter Blocks gefunden... starte Scan nach doppelten Block.
Durchgang 1B: Suche nach doppelten/defekten Blocks
Mehrfach beansprucht Block(s) in Inode 86114492: 4538368 4405248
<< ... removed millions of entries of the same pattern here ... >>
11648685 11648686
Durchgang 1C: Prüfe Verzeichnisse nach Inodes mit doppelten Blocks.
Durchgang 1D: Gleiche doppelte Blocks ab
(es gibt 6 Inodes, die doppelte/defekte Blocks enthalten.)
Datei /Recordings/.../MVI_8559.MOV (Inode #86114492, Modifikationszeitpunkt Sat Mar 24 20:23:54 2012)
hat Block Nr.413455 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8563.MOV (Inode #86114496, mod time Sat Mar 24 20:23:54 2012)
multiply claimed block map? ja
clone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefunden
clone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefunden
Datei /Recordings/.../MVI_8563.MOV (Inode #86114496, Modifikationszeitpunkt Sat Mar 24 20:23:54 2012)
hat Block Nr.413455 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8559.MOV (Inode #86114492, mod time Sat Mar 24 20:23:54 2012)
Duplizierte Blocks bereits neu zugeordnet bzw. geklont.
Datei /Recordings/.../MVI_8571.MOV (Inode #86114504, Modifikationszeitpunkt Sat Mar 24 22:09:56 2012)
hat Block Nr.244958 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8575.MOV (Inode #86114508, mod time Sat Mar 24 22:09:56 2012)
multiply claimed block map? ja
clone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefunden
clone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefunden
Datei /Recordings/.../MVI_8575.MOV (Inode #86114508, Modifikationszeitpunkt Sat Mar 24 22:09:56 2012)
hat Block Nr.244958 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_8571.MOV (Inode #86114504, mod time Sat Mar 24 22:09:56 2012)
Duplizierte Blocks bereits neu zugeordnet bzw. geklont.
Datei /Recordings/.../MVI_3598.MOV (Inode #86376840, Modifikationszeitpunkt Thu Aug 23 21:14:34 2012)
hat Block Nr.45835 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../SomeFile.psd (Inode #86376844, mod time Thu Aug 23 21:14:34 2012)
multiply claimed block map? ja
clone_file_block: interner Fehler; dup_blk für 345554931 wurde nicht gefunden
clone_file_block: interner Fehler; dup_blk für 345554931 wurde nicht gefunden
Datei /Recordings/.../SomeFile.psd (Inode #86376844, Modifikationszeitpunkt Thu Aug 23 21:14:34 2012)
hat Block Nr.45835 doppelte Block(s), gemeinsam genutzt mit 1 Datei(en):
/Recordings/.../MVI_3598.MOV (Inode #86376840, mod time Thu Aug 23 21:14:34 2012)
Duplizierte Blocks bereits neu zugeordnet bzw. geklont.
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
/dev/sdb1: ***** DATEISYSTEM WURDE VERÄNDERT *****
121950 Inodes sind in Benutzung (0.07%)
1244 nicht zusammenhängende Dateien (1.0%)
30 nicht zusammenhängende Verzeichnisse (0.0%)
# von Inodes mit ind/dind/tind Blöcken: 0/0/0
Erweiterungstiefe Histogramm: 121816/126
184589222 Blöcke werden benutzt (25.20%)
0 ungültige Blöcke
4 große Dateien
119827 reguläre Dateien
2114 Verzeichnisse
0 zeichenorientierte Gerätedateien
0 Blockgerätedateien
0 Fifos
11 Verknüpfungen
0 symbolische Verknüpfungen (0 schnelle symbolische Verknüpfungen)
0 Sockets
--------
121952 Dateien
Das lässt mich denken, dass ich keine Möglichkeit habe, einen sauberen Dateisystemstatus zu erhalten, ohne diese Festplatte zu formatieren, oder? Ich habe einen fünften Durchlauf von e2fsck gestartet und würde wetten, dass er wieder einige Probleme findet, genau wie der vierte Durchlauf oben, obwohl die Ausgabe des dritten Durchlaufs so aussah, als wäre er mit seinem Ergebnis zufrieden und hätte sich selbst beendet.
Ich gebe Ihnen ein weiteres Update, wenn der 5. Lauf beendet ist.
UPDATE8:(2012-12-12_1736) Parallel zu meinen Fortschritten hier habe ich mein Problem in Mails beschrieben, die ich an die Mailingliste gesendet habe.[email geschützt]--> und Theodore Ts'o hat meine Mails dort gelesen und mir geholfen. Ich habe ihm ein komprimiertes e2image -Q /dev/sdb1Image dieser Festplatte (Metadaten) geschickt und er hat mir diese Befehle gegeben
debugfs -w /dev/sdb1
debugfs: clri <86114492>
debugfs: clri <86114504>
debugfs: clri <86376840>
debugfs: quit
auszuführen, wodurch der nächste e2fsck-Lauf sehr schnell ging und ich wieder einen sauberen Dateisystemstatus hatte. Ich habe ein paar Dateien verloren, aber die meisten Sachen sind noch da, wo sie waren, bevor die Probleme auftraten. Und ich hatte seitdem keine Probleme mehr mit der Festplatte.
Und hier ist meine Kernel-Version und meine e2fsck-Version von damals (aus einer E-Mail an Ted kopiert):
kaefert@blechmobil:~$ uname -a
Linux blechmobil 3.2.0-3-amd64 #1 SMP Thu Jun 28 09:07:26 UTC 2012
x86_64 GNU/Linux
kaefert@blechmobil:~$ sudo e2fsck -V
e2fsck 1.42.4 (12-Jun-2012)
Benutze EXT2FS Library version 1.42.4, 12-Jun-2012
(Zeiten sind in MEZ)
Antwort1
Mir ist aufgefallen, dass über 47 % Ihrer CPU-Nutzung „auf Null gesetzt“ ist (d. h. mit langsamerer Priorität als normal läuft). Könnte das der fsck-Prozess sein? Wenn ja, würde ich vorschlagen, dass Sie ihn zumindest auf normale Priorität zurücksetzen. Dies könnte der Grund für die Langsamkeit sein.
Antwort2
uname -a, bitte :) Ich denke, es ist Theodore Tsos Fehler im Kernel 3.x:https://lkml.org/lkml/2012/10/23/690