我有这个外部的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! ...
所以我去了，并开始我最喜欢的分区pipe理器 – gparted，并告诉它来validation和修复分区sdb1。 这使得g2ed呼叫e2fsck（版本1.42.4（12-Jun-2012））
e2fsck -f -y -v /dev/sdb1
尽pipegparted用“-v”选项调用了e2fsck，可惜的是它并没有显示我的e2fsck进程的输出（bugreport https://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运行缓慢的post，例如：
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
但是，尽pipe我可以从该磁盘快速读取，但是考虑到像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/sr/sw/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在所有处理器上的时间，并find了工具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千兆字节，这是一个3TB的磁盘，如果速度保持不变，e3fsck会像这样完成扫描只有一次。
你有什么build议吗？ 我在其他地方的大部分数据都在这个磁盘上，但是我已经花了很多时间来sorting和合并到这个磁盘上，所以我宁愿让这个磁盘重新开始运行，而不用重新格式化。 我不认为硬件损坏，因为磁盘只有几个月，因为我看不到在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.29TB，所以它似乎不是一个大规模的线性进展，也许只有一些需要工作的领域，两者之间有很大的差距。
UPDATE2：奥基 ，大失望，数字又回到很小（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会多次遍历数据，或者只是多次来回跳转。 或者我的假设，这些数字是字节是错误的。
UPDATE3：因为在这里提到
http://forums.fedoraforum.org/showthread.php?t=282125&page=2
你可以在e2fsck运行的时候testing磁盘，我试过了，虽然没有很多的成功。 当询问testing磁盘显示我的分区的数据时，这是我得到的：
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.
这是目前给我的（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： （2012-11-08_0800）Okey，所以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
它崩溃之前，让我select了一个位置来保存细节，所以它甚至没有开始写这些细节到一个文件。 所以我什么也没有，只是在e2fsck输出的5行左右闪现了一些关于它正在修复的损坏的节点。 我的猜测是，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 (dh 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
UPDATE5： （2012-11-08_2130）Okey，所以e2fsck已经运行了大约12个小时，至less有10个自我上面贴出的最后一行被打印。 我担心这将再次花费80个小时完成（或失败），就像我第一次看到这种模式一样。
UPDATE6： （2012-11-09_0653）我在上面运行的第三个e2fsck的控制台输出中添加了一些新行（他问了第二个问题，现在回到下面描述的输出模式，并由gkrellm屏幕截图。
UPDATE7： （2012-11-11_1839）Soooo ..结束了。 这里是它打印的最后几行：
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的第五轮比赛，我会再次打赌，就像上面第四轮那样，发现了一些问题，尽pipe第三轮的输出看起来像是对他的结果感到高兴，并终止了自己。
第五次运行结束后，我会给你另一个更新。
UPDATE8： （2012-12-12_1736）与此同时发布我的进度，我已经描述了我发送到邮件列表[email protected] – >和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
（时间在CET）
我注意到超过47％的CPU使用“niced”（即以低于正常的优先级运行）。 难道这是fsck过程？ 如果是这样的话，我可能会build议你把它重新调整到至less正常的优先级。 这可能是缓慢的原因。
uname -a，请:)我猜这是Theodore Tso在内核3.x中的错误： https ： //lkml.org/lkml/2012/10/23/690