web-dev-qa-db-ja.com

十分なメモリが存在しますが、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（2012年6月12日））が作成されました。

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=1361

ここで、ディスクが損傷している可能性があるためにディスクがそれほど遅いかどうかを確認することをお勧めします。これらの出力は、私の場合はそうではないことを示していると思います。

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ギガバイトのようなものになります。これは3テラバイトのディスクであり、速度が一定である場合、残り134日で、e2fsckはこのようにディスクを完全にスキャンします。そして一度だけ。

何かアドバイスはありますか？そのディスクにはほとんどのデータがありますが、並べ替えてこのディスクにマージするのに多くの時間を費やしているので、このディスクを新たにフォーマットせずに、再度起動して実行したいと思います。ディスクが数か月しかなく、dmesg出力にI/Oエラーが表示されないため、ハードウェアが損傷しているとは思いません。

UPDATE：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テラバイトを表します。したがって、大規模な直線的な進行ではないようです。作業が必要な領域で、それらの間に大きなギャップがあります。

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の実行中に証言できることを試してみましたが、あまり成功していません。 testdiskにパーティションのデータを表示するように要求すると、次のようになります。

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.

そしてこれは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に詳細を保存させると、応答が停止し、コアの1つで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行で、修復中の損傷したiノードについて何かを述べたquckを垣間見るだけです。私の推測では、e2fsckの出力は非常に長いため、gpartedはそれを処理できず、試行するとクラッシュしました。

これは、失敗するまで実行された最後の1分間の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）上記の3番目のe2fsck実行のコンソール出力にいくつかの新しい行を追加しました（彼は2番目に尋ねました質問、そして今、それは出力の下で説明され、そのgkrellmスクリーンショットによって視覚化されたパターンに戻ります。

UPDATE7：（2012-11-11_1839）すっごく..終了しました。印刷されたものの最後の数行は次のとおりです。

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」に何かを入れなければなりませんでした。

そして、今は本当にきれいだと彼を信じていなかったので、4回実行しましたが、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回目の実行を開始しましたが、3回目の実行の出力は彼の結果に満足しているように見え、自分自身を終了しましたが、上記の4回目の実行と同じようにいくつかの問題を見つけることに再び賭けます。

5回目の実行が終了したら、別の更新を提供します。

UPDATE8：（2012-12-12_1736）ここに進捗状況を投稿するのと並行して、メーリングリストに送信したメールで問題を説明しました[email protected]>そしてTheodoreTs'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です）

linuxfilesystemshard-drivedata-recoveryext4
5
kaefert

使用されているCPUの47％以上が「ニック」されている（つまり、通常よりも遅い優先度で実行されている）ことに気付きました。これはfsckプロセスでしょうか？もしそうなら、私はあなたが少なくとも通常の優先順位にそれを放棄することを提案するかもしれません。これが遅い理由かもしれません。

1
mdpc

uname -a、お願いします:)カーネル3.xのTheodore Tsoのバグだと思います： https://lkml.org/lkml/2012/10/23/69

0
GioMac