我有這個外部 USB 磁碟：
kaefert@blechmobil:~$ lsusb -s 2:3
Bus 002 Device 003: ID 0bc2:3320 Seagate RSS LLC
從 dmesg 輸出可以看出，存在一些問題導致無法安裝該磁碟：
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!
...
所以我啟動了我最喜歡的分區管理器 - gparted，並告訴它驗證並修復分區 sdb1。這使得 gparted 呼叫 e2fsck（版本 1.42.4 (12-Jun-2012)）
e2fsck -f -y -v /dev/sdb1
雖然 gparted 使用“-v”選項來呼叫 e2fsck，但遺憾的是它沒有顯示 e2fsck 程序的輸出（bugreporthttps://bugzilla.gnome.org/show_bug.cgi?id=467925）
我在周日（2012-11-04_2200）晚上開始了這整件事，所以大約48小時前，這就是htop現在所說的（2012-11-06-1900）：
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
現在我在網上找到了一些討論 e2fsck 運行緩慢的帖子，例如：
http://gparted-forum.surf4.info/viewtopic.php?id=13613
他們寫道，最好看看磁碟是否那麼慢，因為可能已損壞，我認為這些輸出告訴我，我的情況並非如此：
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
然而，雖然我可以從該磁碟快速讀取，但考慮到 gkrellm 或 iotop 等工具，e2fsck 似乎不使用這種磁碟速度：
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
現在我研究了一些如何找出 e2fsck 在所有處理器時間上做什麼，我找到了工具 strace，它給了我這個：
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
每秒大約 16 行，所以每秒 4 次讀取和 4 次寫入操作，我認為這不是很多。
最後，我的問題是：這個過程會結束嗎？如果 fseek (48404774912) 中的這些數字代表字節，則大約為 45 GB，而這是一個 3 TB 的磁碟，如果速度保持不變，這將給我 134 天的時間，並且 e2fsck 像這樣完全掃描磁碟並且只有一次。
你有什麼建議給我嗎？我的大部分資料都在該磁碟上的其他地方，但我花了很多時間來排序並將其合併到該磁碟上，因此我更願意再次啟動該磁碟並運行，而無需重新格式化它。我不認為硬體已損壞，因為磁碟只有幾個月，而且我在 dmesg 輸出中看不到任何 I/O 錯誤。
更新：我剛剛再次查看了 strace 輸出（2012-11-06_2300），現在看起來像這樣：
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
因此，讀取之前的 lseek 行中的數字（例如 1419860619264）已經大得多，如果這些數字是字節，則代表 1.29 TB，因此它似乎不是大規模的線性進展，也許只有一些需要工作的領域，它們之間存在很大差距。
更新2：好吧，非常失望，數字又回到很小的水平 (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
因此，e2fsck 要么多次檢查數據，要么只是來回跳躍多次。或者我認為這些數字是位元組的假設是錯誤的。
更新3：既然這裡提到了
http://forums.fedoraforum.org/showthread.php?t=282125&page=2
你可以在 e2fsck 運行時進行測試，我嘗試過，但沒有取得很大成功。當要求 testdisk 顯示我的分割區的資料時，這就是我得到的：
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.
這就是 strace 目前給我的（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
更新4：(2012-11-08_0800) 好吧，所以e2fsk 進程在超過78 小時後失敗（這就是gparted 寫的），當我嘗試讓gparted 保存詳細信息時，它停止響應，佔用了我的一個核心的100% cpu 時間幾分鐘，然後在控制台中列印此行崩潰：
/usr/sbin/gpartedbin: symbol lookup error: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: undefined symbol: g_mutex_lock
在它讓我選擇保存詳細資訊的位置之前它就崩潰了，所以它甚至沒有開始將這些詳細資訊寫入文件。所以我什麼也沒有得到，只是快速瞥見了 e2fsck 輸出的大約 5 行，其中說明了有關它正在修復的損壞 inode 的信息。我的猜測是 e2fsck 的輸出太長，以至於 gparted 無法處理它並在嘗試時崩潰。
這是 gparted-bin 進程在運行的最後一分鐘直至失敗的 strace 輸出：
http://pastebin.ubuntu.com/1341922/
現在我重新啟動了我的筆記本，我很驚訝地看到了這一點：
[ 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)
所以他設法再次掛載檔案系統，乍一看看起來不錯，但根據上面 dmesg 輸出的建議，我開始再次運行 e2fsck，但這次是手動運行，沒有 gparted 作為中間：
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)
所以我要這樣做，現在就從來不使用 -p 參數開始。由於上面的 e2fsck 運行只花了大約 2 個小時，我想我會在大約 2 小時後給你另一個更新。
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
現在 e2fsck 的第一次極長運行的模式似乎正在重複。 strace 輸出看起來相同，磁碟使用情況的 gkrellm 表示也相同（見下文）。距離我上面發布的最後一次輸出已經過去了大約 2 個小時。
gkrellm 磁碟使用情況的表示 http://kaefert.is-a-geek.org/misc/e2fsck_disk_usage_pattern_gkrellm.png
更新5：(2012-11-08_2130) 好的，e2fsck 已經再次運行了大約 12 個小時，並且自我上面發布的最後一行以來至少已經運行了 10 個小時。恐怕這將再次需要 80 小時才能完成（或失敗），就像我第一次看到這種模式時一樣。
更新6：(2012-11-09_0653) 我在上面第三次e2fsck 運行的控制台輸出中添加了一些新行（他問了第二個問題，現在又回到了輸出下面描述的模式，並通過gkrellm 屏幕截圖進行了可視化。
更新7：(2012-11-11_1839) 嗚嗚嗚..結束了。以下是它列印的最後幾行：
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
我必須在字母“j”上寫一些東西來回答這數百萬個問題。
由於我不相信他現在真的乾淨了，所以我運行了第四次，e2fsck 承認並非一切都正確，他仍然給自己留下了待辦事項：
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
所以這讓我想，如果不格式化該磁碟，我就無法獲得乾淨的檔案系統狀態，對嗎？我已經開始第五次運行 e2fsck，我敢打賭它會再次發現一些問題，就像上面第四次運行一樣，儘管第三次運行的輸出看起來他對結果很滿意並終止了自己。
第五次運行結束後，我將向您提供另一個更新。
更新8：(2012-12-12_1736) 在這裡發布我的進度的同時，我在發送到郵件列表的郵件中描述了我的問題[電子郵件受保護]--> Theodore Ts'o 在那裡閱讀了我的郵件，並幫助了我。我已經向他發送了e2image -Q /dev/sdb1該磁碟的壓縮映像（元資料），他給了我這些命令
debugfs -w /dev/sdb1
debugfs: clri <86114492>
debugfs: clri <86114504>
debugfs: clri <86376840>
debugfs: quit
運行，這使得下一個 e2fsck 運行得非常快，並再次給了我一個乾淨的檔案系統狀態。我丟失了一些文件，但大部分內容仍然在問題出現之前的位置。從此我的磁碟就沒有出現任何問題。
這是我當時的核心版本和 e2fsck 版本（從發給 Ted 的郵件中複製）：
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
（時間為歐洲中部時間）
答案1
我注意到超過 47% 的 CPU 使用率是「niced」（即以低於正常優先權的速度運行）。這可能是 fsck 過程嗎？如果是這樣，我可能建議您至少將其調整為正常優先順序。這可能是緩慢的原因。
答案2
uname -a，請:)我猜這是 Theodore Tso 在內核 3.x 中的錯誤：https://lkml.org/lkml/2012/10/23/690