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

前端之家收集整理的这篇文章主要介绍了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,"\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"...,41027002368,SEEK_SET)         = 41027002368
write(4,"\232]7Ws\321\352\t\1@[+5\263\334\276{\343zZx\352\21\316`1\271[\202\350R`"...,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"...,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#"...,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千兆字节,这可能是一个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:"...,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."...,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"...,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"...,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"...,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太字节,因此它似乎不是大规模的线性进展,也许只有一些需要工作的领域,它们之间存在很大差距.

更新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"...,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 <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"...,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

在它让我选择保存详细信息的位置之前它崩溃了,因此它甚至没有开始将这些细节写入文件.所以我只有一个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)

解决方法

我注意到超过47%的cpu使用了“niced”(即运行速度低于普通优先级).这可能是fsck过程吗?如果是这样,我可能会建议您将其重新设置为至少正常的优先级.这可能是缓慢的原因.
原文链接:https://www.f2er.com/linux/398307.html

猜你在找的Linux相关文章