이 외부 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 파티션을 확인하고 복구하라고 지시했습니다. 이로 인해 e2fsck 호출이 gparted되었습니다(버전 1.42.4(2012년 6월 12일)).
e2fsck -f -y -v /dev/sdb1
gparted가 "-v" 옵션을 사용하여 e2fsck를 호출했지만 슬프게도 e2fsck 프로세스의 출력을 표시하지 않습니다(버그 보고서https://bugzilla.gnome.org/show_bug.cgi?id=467925)
나는 이 모든 일을 일요일(2012-11-04_2200) 저녁에 시작했으므로 약 48시간 전, 이것이 지금(2012-11-06-1900)에 대해 htop이 말하는 것입니다:
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기가바이트 정도가 되며, 이는 3테라바이트 디스크가 됩니다. 속도가 일정하게 유지되고 e2fsck가 이와 같이 디스크를 완전히 스캔하는 경우 134일이 소요됩니다. 그리고 딱 한 번만.
나에게 조언이 있나요? 해당 디스크의 대부분의 데이터는 다른 곳에 있지만 이를 정렬하고 이 디스크에 병합하는 데 많은 시간을 투자했기 때문에 이 디스크를 새로 포맷하지 않고 다시 실행하고 싶습니다. 디스크가 몇 달 밖에 안됐고 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테라바이트에 해당하므로 큰 규모에서 선형적인 진행이 아닌 것 같습니다. 아마도 일부만 있을 수 있습니다. 작업이 필요한 영역과 그 사이에 큰 격차가 있는 영역입니다.
업데이트 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는 데이터를 여러 번 검토하거나 여러 번 앞뒤로 홉합니다. 또는 그 숫자가 바이트라는 나의 가정은 잘못되었습니다.
업데이트3:여기서 언급한 이후로
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
업데이트 4:(2012-11-08_0800) 알겠습니다. e2fsk 프로세스는 78시간이 지난 후 실패했고(gparted가 쓴 것입니다) gparted가 세부 정보를 저장하도록 하려고 했을 때 응답이 멈추고 코어 중 하나의 CPU 시간이 100% 걸렸습니다. 몇 분 동안 콘솔에 다음 줄을 인쇄하는 중 충돌이 발생했습니다.
/usr/sbin/gpartedbin: symbol lookup error: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so: undefined symbol: g_mutex_lock
세부 정보를 저장할 위치를 선택하기 전에 충돌이 발생했기 때문에 해당 세부 정보를 파일에 쓰기도 시작하지 않았습니다. 그래서 나는 복구 중이던 손상된 inode에 대해 언급한 e2fsck 출력의 약 5줄을 잠깐 훑어볼 뿐 아무것도 얻지 못했습니다. 내 생각엔 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
업데이트5:(2012-11-08_2130) 좋습니다. e2fsck는 이미 약 12시간 동안 다시 실행되었으며 위에 게시한 마지막 줄이 인쇄된 이후로 그 중 최소 10시간이 인쇄되었습니다. 이 패턴을 처음 봤을 때처럼 완료(또는 실패)하는 데 다시 80시간이 걸릴 것 같습니다.
업데이트 6:(2012-11-09_0653) 위에서 실행한 세 번째 e2fsck의 콘솔 출력에 몇 가지 새로운 줄을 추가했습니다. (그가 두 번째 질문을 했고 이제 출력 아래에 설명되어 있고 gkrellm 스크린샷으로 시각화된 패턴으로 돌아왔습니다.
업데이트7:(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"에 뭔가를 넣어야 했습니다.
그리고 나는 그가 지금 정말 깨끗하다고 믿지 않았기 때문에 네 번째로 실행했고 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회차가 끝나면 또 소식 전해드리겠습니다.
업데이트8:(2012-12-12_1736) 여기에 진행 상황을 게시하는 것과 병행하여 메일링 리스트에 보낸 메일에서 내 문제를 설명했습니다.[이메일 보호됨]--> 그리고 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 기준)
답변1
사용된 CPU의 47% 이상이 "좋은" 것(즉, 일반 우선 순위보다 느린 속도로 실행)인 것으로 나타났습니다. 이것이 fsck 프로세스일 수 있습니까? 그렇다면 최소한 일반적인 우선순위로 이를 거부하는 것이 좋습니다. 이것이 느린 이유일 수 있습니다.
답변2
uname -a, 제발 :) 커널 3.x의 Theodore Tso의 버그인 것 같습니다.https://lkml.org/lkml/2012/10/23/690