linux – e2fsck非常慢,虽然存在足够的内存

我有这个外置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进程的输出(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运行缓慢的帖子,例如：

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,"212354K[_3613nl212245352255jR303354312Yv334p253r21726535673252573766"...,4096) = 4096
lseek(4,48404766720,SEEK_SET)         = 48404766720
read(4,"7t26036634633730421033267j35377'31f372252ffU317.y21136036240c30`34"...,41027002368,SEEK_SET)         = 41027002368
write(4,"232]7Ws321352t1@[+5263334276{343zZx35221316`1271[202350R`"...,48404770816,SEEK_SET)         = 48404770816
read(4,"17362r23032725346//210Hv3113237323K304306361a223311324272?213tq 37024"...,41027006464,SEEK_SET)         = 41027006464
write(4,"367yy>x216?=324Z305351376&2524421027122306}276237370(214205G262360257#"...,48404774912,SEEK_SET)         = 48404774912
read(4,"3652521|T21}3t_272373222kr1773031201261221$261B232314221U316"...,4096) = 4096
^CProcess 3704 detached

每秒大约有16条线路,所以每秒4次读取和4次写入操作,我不认为这很多.

最后,我的问题是：这个过程会完成吗？如果来自fseek(48404774912)的那些数字表示字节,那将是45千兆字节,这可能是一个3 TB的磁盘,如果速度保持不变,这将给我134天的时间,并且e2fsck像这样完全扫描磁盘而且只有一次.

你有什么建议吗？我在其他地方的磁盘上有大部分数据,但是我已经花了很多时间对它进行排序并将它合并到这个磁盘上,所以我宁愿让这个磁盘重新启动并再次运行,而不是重新格式化.我不认为硬件损坏,因为磁盘只有几个月,因为我在dmesg输出中看不到任何I / O错误.

更新：我刚看了一下strace输出(2012-11-06_2300),现在它看起来像这样：

lseek(4,1419860611072,SEEK_SET)       = 1419860611072
read(4,"3#f244733522A355374276j204'207|217V|23245[7VP251242276207317:"...,43018145792,SEEK_SET)         = 43018145792
write(4,"]206231342Y204-2I3622423446R205361324177265317C334V324260334275t=10F."...,1419860615168,SEEK_SET)       = 1419860615168
read(4,"262305314Y36737x326245226226320N333$s342043112227315236336300TK337264236211n"...,43018149888,SEEK_SET)         = 43018149888
write(4,"271224m31122425!I37616;377223H25Yd201Y342r20327124eG<202{373V"...,1419860619264,SEEK_SET)       = 1419860619264
read(4,";d360177n346253210222|250352T335M332603202617g222P344H?t240202548310"...,43018153984,SEEK_SET)         = 43018153984
write(4,"360252j317310251G227335{214`34126731Y202360v374307oq3063217Z22331336D211"...,4096) = 4096

因此,读取之前的lseek行中的数字,如1419860619264已经大了很多,如果这些数字是字节,则代表1.29太字节,因此它似乎不是大规模的线性进展,也许只有一些需要工作的领域,它们之间存在很大差距.

更新2：好吧,非常失望,这些数字又回到了很小的位置(2012-11-07_0720)

lseek(4,52174548992,SEEK_SET)         = 52174548992
read(4,"3743122232521521323357U222246370v^f(312|f2123623433753733424204mU6"...,46603526144,SEEK_SET)         = 46603526144
write(4,"37026122322723?44217264320_Am246CQ313^203U2532742042772564n227177267343"...,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 <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,"315Mb265v377Gn 24f205EHh2349~330273203337520610r3=W210372352"...,47347830784,SEEK_SET)         = 47347830784
write(4,"]204223300I35742633+243312G230250371*m2Ut_215265J 252342Pm360D"...,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

在它让我选择保存详细信息的位置之前它崩溃了,因此它甚至没有开始将这些细节写入文件.所以我只有一个quck glimps在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,idProduct=3320
[    1.501585] usb 2-1: New USB device strings: Mfr=2,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,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,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,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 representation of the disk usage http://kaefert.is-a-geek.org/misc/e2fsck_disk_usage_pattern_gkrellm.png

更新5：(2012-11-08_2130)Okey,所以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,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,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,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,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,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

所以这让我觉得,没有格式化这个磁盘,我无法获得干净的文件系统状态,对吗？我已经开始第5次运行e2fsck了,我打赌它再次找到一些问题就像上面的第4次运行一样,虽然第3次运行的输出看起来像他对自己的结果感到高兴并终止了自己.

第五轮比赛结束后,我会给你另一个更新.

更新8：(2012-12-12_1736)
在这里发布我的进展的同时,我已经在邮件列表中描述了我的问题linux-ext4@vger.kernel.org – >和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)