kae*_*ert 5 linux filesystems ext4 hard-drive data-recovery
我有这个外部 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 进程的输出（错误报告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运行缓慢的帖子，例如：
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 多次遍历数据，要么只是来回跳跃多次。或者我认为这些数字是字节的假设是错误的。
UPDATE3：因为它在这里提到
http://forums.fedoraforum.org/showthread.php?t=282125&page=2
你可以在 e2fsck 运行时进行测试，我试过了，虽然没有取得很大的成功。当要求 testdisk 显示我的分区的数据时，这就是我得到的：
TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
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
UPDATE4: (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
UPDATE5: (2012-11-08_2130) 好吧，所以 e2fsck 已经再次运行了大约 12 个小时，并且自我在上面发布的最后一行以来至少打印了 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 的第 5 次运行，我会再次打赌它会发现一些问题，就像上面的第 4 次运行一样，尽管第 3 次运行的输出看起来他对结果很满意并终止了自己。
当第 5 次运行结束时，我会给你另一个更新。
UPDATE8: (2012-12-12_1736) 在在这里发布我的进展的同时，我已经在我发送到邮件列表 linux-ext4@vger.kernel.org --> 和 Theodore Ts 的邮件中描述了我的问题o 在那里阅读了我的邮件，并帮助了我。我已经向他发送了e2image -Q /dev/sdb1该磁盘的压缩图像（元数据），他给了我这些命令
debu
我注意到超过 47% 的 CPU 使用率是“niced”（即以低于正常优先级的速度运行）。这可能是 fsck 过程吗？如果是这样，我可能建议您至少将其调整为正常优先级。这可能是缓慢的原因。
| 归档时间： |
|
| 查看次数： |
3814 次 |
| 最近记录： |