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

概述我有这个外置USB盘： kaefert@blechmobil:~$lsusb -s 2:3Bus 002 Device 003: ID 0bc2:3320 Seagate RSS LLC 从这个dmesg输出中可以看出,存在一些阻止磁盘安装的问题： kaefert@blechmobil:~$dmesg...[ 113.084079] usb 2-1: new high-speed USB 我有这个外置USB盘：

kaefert@blechmobil:~$lsusb -s 2:3Bus 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/seckaefert@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 -xlinux 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,37Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %utilsda               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,99sdb             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 -p3704lseek(4,41026998272,SEEK_SET)         = 41026998272write(4,"24K[_1nl2525jR342Yv4p3r75675766"...,4096) = 4096lseek(4,48404766720,SEEK_SET)         = 48404766720read(4,"t0667407j7'f22\ffU7.y100c`"...,41027002368,SEEK_SET)         = 41027002368write(4,"2]7Ws12\t@[+5346{3zZx26`11[20R`"...,48404770816,SEEK_SET)         = 48404770816read(4,"2r076//0H\v1373K461a3142?3\tq 0"...,41027006464,SEEK_SET)         = 41027006464write(4,"7yy>x6?=4Z516&4016}670(45G207#"...,48404774912,SEEK_SET)         = 48404774912read(4,"5
lseek(4,1419860611072,SEEK_SET)       = 1419860611072read(4,"3#\f475
lseek(4,52174548992,SEEK_SET)         = 52174548992read(4,"42\55357U260v^f(2|f2235324mU6"...,46603526144,SEEK_SET)         = 46603526144write(4,"0137?740_Am6CQ3^3U344764n7773"...,4096) = 4096
A546j4'7|7V|5[VP12677:"...,43018145792,SEEK_SET)         = 43018145792write(4,"]612Y4-2I224R514757C4V4045t=F."...,1419860615168,SEEK_SET)       = 1419860615168read(4,"254Y7x65660N3$s4125660TK7461n"...,43018149888,SEEK_SET)         = 43018149888write(4,"14m14!I6;7
Testdisk 6.13,Data Recovery Utility,November 2011Christophe GRENIER <grenIEr@cgsecurity.org>http://www.cgsecurity.org 1 P linux                    0   4  5 45600  40  8  732566272Can't open filesystem. filesystem seems damaged.
3HYd1Y2\r31eG<2{3V"...,1419860619264,SEEK_SET)       = 1419860619264read(4,";d07\n6302|02T5M001g2P4H?t0480"...,43018153984,SEEK_SET)         = 43018153984write(4,"02j701G75{4`17Y20\v47oq637Z33D1"...,4096) = 4096
|T
lseek(4,212460343296,SEEK_SET)        = 212460343296read(4,"5Mb5v7Gn \f5EHh49~033756\r3=W022"...,47347830784,SEEK_SET)         = 47347830784write(4,"]430I7+32G001*m2U\t_55J 22Pm0D"...,4096) = 4096
}3t_232k\r73111$1B242U6"...,4096) = 4096^CProcess 3704 detached

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

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

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

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

/usr/sbin/gpartedbin: symbol lookup error: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: undefined symbol: g_mutex_lock

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

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

[    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)

所以要么e2fsck多次遍历数据,要么只是多次来回跳跃.或者我假设这些数字是字节是错误的.

更新3：因为这里提到了

http://forums.fedoraforum.org/showthread.php?t=282125&page=2

你可以在e2fsck运行的时候测试它,我试过了,虽然没有取得很大的成功.当要求testdisk显示我的分区数据时,这就是我得到的：

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 verdoppelnext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294960577 for Den Eintrag in der Liste belegter Blöcke verdoppelnext2fs_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)

这就是strace目前给我的(2012-11-07_1030)

kaefert@blechmobil:~$sudo e2fsck -v /dev/sdb1e2fsck 1.42.4 (12-Jun-2012)/dev/sdb1 enthält ein fehlerhaftes Dateisystem,Prüfung erzwungen.Durchgang 1: Prüfe Inodes,Blocks,und GrößenDoppelter Blocks gefunden... starte Scan nach doppelten Block.Durchgang 1B: Suche nach doppelten/defekten Blocksext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294954142 for Den Eintrag in der Liste belegter Blöcke verdoppelnext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294960577 for Den Eintrag in der Liste belegter Blöcke verdoppelnext2fs_test_block_bitmap wurde eine unzulässige Blocknummer übergeben #4294902002 for Den Eintrag in der Liste belegter Blöcke verdoppelnMehrfach beansprucht Block(s) in Inode 86114492: 4538368 3365377 3365378 3365379 3365380 ... 9455459Durchgang 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>? jaclone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefundenclone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefundenDatei /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>? jaclone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefunden

UPDATE4：(2012-11-08_0800)Okey,所以e2fsk进程在78小时后失败了(这就是gparted所写的内容)当我试图让gparted保存详细信息时,它停止响应,占用了100％的cpu时间之一我的核心几分钟,然后在控制台中崩溃打印这条线：

DIE Anzahl Verzeichnisse ist falsch für Gruppe #20192 (0,gezählt=1).ReparIEre<j>? jaDIE Anzahl freIEr Inodes ist falsch für Gruppe #20576 (8192,gezählt=8143).ReparIEre<j>? jaDIE Anzahl Verzeichnisse ist falsch für Gruppe #20576 (0,gezählt=3).ReparIEre<j>? jaDIE Anzahl freIEr Inodes ist falsch für Gruppe #21472 (8192,gezählt=8182).ReparIEre<j>? jaDIE Anzahl Verzeichnisse ist falsch für Gruppe #21472 (0,gezählt=1).ReparIEre<j>? jaDIE 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/126184589222 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

在它让我选择保存详细信息的位置之前它崩溃了,因此它甚至没有开始将这些细节写入文件.所以我只有一个quck glimps在e2fsck输出的大约5行,它说明了它正在修复的损坏的inode.我的猜测是,e2fsck的输出非常长,gparted无法处理它并在尝试时崩溃.

这是gparted-bin进程在运行的最后一分钟直到失败时的strace输出：

http://pastebin.ubuntu.com/1341922/

现在我重新启动了我的笔记本,看到这个我感到非常惊讶：

kaefert@blechmobil:~$sudo e2fsck -f -y -v /dev/sdb1e2fsck 1.42.4 (12-Jun-2012)Durchgang 1: Prüfe Inodes,und GrößenDoppelter Blocks gefunden... starte Scan nach doppelten Block.Durchgang 1B: Suche nach doppelten/defekten BlocksMehrfach beansprucht Block(s) in Inode 86114492: 4538368 4405248<< ... removed millions of entrIEs of the same pattern here ... >> 11648685 11648686Durchgang 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? jaclone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefundenclone_file_block: interner Fehler; dup_blk für 4538368 wurde nicht gefundenDatei /Recordings/.../MVI_8563.MOV (Inode #86114496,mod time Sat Mar 24 22:09:56 2012)multiply claimed block map? jaclone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefundenclone_file_block: interner Fehler; dup_blk für 7999488 wurde nicht gefundenDatei /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? jaclone_file_block: interner Fehler; dup_blk für 345554931 wurde nicht gefundenclone_file_block: interner Fehler; dup_blk für 345554931 wurde nicht gefundenDatei /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 StrukturDurchgang 3: Prüfe Verzeichnis VerknüpfungenDurchgang 4: Überprüfe dIE ReferenzzählerDurchgang 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/126184589222 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

所以他设法再次挂载文件系统,乍一看它看起来没问题,但是正如上面的dmesg输出所推荐的那样,我开始再次运行e2fsck,但这次手动没有gparted作为中间：

deBUGfs -w /dev/sdb1deBUGfs: clri <86114492>deBUGfs: clri <86114504>deBUGfs: clri <86376840>deBUGfs: quit

所以我会这样做,现在开始没有-p参数.由于上面的e2fsck运行大约需要2个小时,我想我会在大约2个小时内给你另一个更新.

kaefert@blechmobil:~$uname -alinux blechmobil 3.2.0-3-amd64 #1 SMP Thu Jun 28 09:07:26 UTC 2012x86_64 GNU/linuxkaefert@blechmobil:~$sudo e2fsck -Ve2fsck 1.42.4 (12-Jun-2012)        Benutze EXT2FS library version 1.42.4,12-Jun-2012

现在,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 ..结束了.以下是它印刷的最后几行：

我不得不在字母“j”上加上一些东西来回答数百万个问题.

因为我现在不相信他真的很干净,所以我第四次跑了,e2fsck承认并非一切都是正确的,他仍然留下了自己的东西：

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

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

更新8：(2012-12-12_1736)
在这里发布我的进展的同时,我已经在邮件列表中描述了我的问题linux-ext4@vger.kernel.org – >和Theodore Ts’o在那里看了我的邮件,并帮助了我.我给他发了一张压缩的e2image -Q / dev / sdb1那个磁盘的图像(元数据),他给了我这些命令

运行,这使得下一个e2fsck运行得非常快,并再次给了我一个干净的文件系统状态.我丢失了一些文件,但大部分内容仍然存在于问题开始之前.从那以后我对磁盘没有任何问题.

这是我的内核版本和我当时的e2fsck版本(从邮件复制到Ted)：

(时间在CET)

解决方法 我注意到超过47％的cpu使用了“niced”(即运行速度低于普通优先级).这可能是fsck过程吗？如果是这样,我可能会建议您将其重新设置为至少正常的优先级.这可能是缓慢的原因. 总结

以上是内存溢出为你收集整理的linux – e2fsck非常慢,虽然存在足够的内存全部内容，希望文章能够帮你解决linux – e2fsck非常慢,虽然存在足够的内存所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。