またまた, 12T RAID5 がおかしくなり, SAMBA 系由で file が見えなくなった.
Ubuntu 上からも見えなくなった. というのも, この Ubuntu マシンは足元に置いていて, オットマン状態になっていて, ちょっとした拍子で PC を動かしてしまった. その時に eSATA が unlink 状態になったのだろうと想像される.
reboot 後, 普通に fsck が通ると思ったのだが, 全く通らない. とりあえず 1日待っても fsck が通らない. というか fsck 自体が cpu load avarage が 100% のままずーと進まない状態になっていた.
root@xxx:/home/yyy# fsck -y /dev/sdb
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb contains a file system with errors, check forced.
Pass 1: Checking iノードs, blocks, and sizes
Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in iノード 12: 375912184
Multiply-claimed block(s) in iノード 56102605: 120293546
Multiply-claimed block(s) in iノード 256639065: 1029258958
Multiply-claimed block(s) in iノード 586416835: 898879174
Multiply-claimed block(s) in iノード 717885620: 375912184 1029258958 120293546 898879174
Illegal block number passed to ext2fs_test_block_bitmap #3422481702 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #4258085766 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #2964345158 for multiply claimed block map
Pass 1C: Scanning directories for iノードs with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 5 iノードs containing multiply-claimed blocks.)
File /disk1 (iノード #12, mod time Wed Mar 11 22:20:48 2015)
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
とりあえず file.img がおかしい事がわかったが, fsck が通せないので, とりあえず mount して ls すると以下の通り
超絶おかしな状態になっていた.
-rw-rw-r-- 1 ppp sssss 890 7月 5 07:08 file.20190716a.txt.1~
-????????? ? ? ? ? ? file.201907170.dat
drws--x--- 34433 343389890 1888527826 49152 8月 12 1964 file.201907170.img
-????????? ? ? ? ? ? file.201907170.tar.gz
-????????? ? ? ? ? ? file.201907170.txt
-????????? ? ? ? ? ? file.201907170.txt.1~
-????????? ? ? ? ? ? file.201907170.txt.2~
-????????? ? ? ? ? ? file.20190724a.dat
s--Srwx-wt 40825 4203306669 2869282342 0 3月 31 1979 file.20190724a.img
-????????? ? ? ? ? ? file.20190724a.tar.gz
-????????? ? ? ? ? ? file.20190724a.txt
-rw-rw-r-- 1 ppp sssss 558035 7月 26 07:07 file.201907260.dat
-rw-rw-r-- 1 ppp sssss 189880 7月 26 07:05 file.201907260.img
-????????? ? ? ? ? ? file.201907260.tar.gz
-????????? ? ? ? ? ? file.201907260.txt
-rw-rw-r-- 1 ppp sssss 1060 7月 26 07:12 file.201908xx0.txt
-????????? ? ? ? ? ? file.txt
permission, uid, gid などが ??? になってしまっている. またそうでなかったとしても regular file が directory file になっていたりする.
とにかく, ほとんど file はなくてもなんとかなりそうだが, file.txt は残しておきたいと思ったのだが, copy しようにも I/O error となる. おかしな状態のものは抹殺しようと rm したがこれまた I/O error となる. ls -il で inode を表示させても ? 状態でとにかく何もできない... file の情報だけあった inode は開放されているのではないかと思う.
そこで, とにかく file 情報を消す方法がないかと調べてみると debugfs でできそうな感じがし, とりあえず debugfs を動作させた.
debugfs -w /dev/sdb
多少挙動が違うが, 一般的な shell の様 cd, ls が使えた. ただ ls は less 想像のものが動作し, 微妙に使いずらい. また, console の history に残っていないので, どの様に表示されたかなどここに書く為の情報はなくなってしまっている. ただ, やった事はとりあえずすべての ? 状態の file を rm していった.
すべての ? 状態の file を消し, debugfs を抜け再度 fsck してもやはり,
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
file.201907170.img は "drws--x---" の file で, regular file が directory file になってしまっている. しかも suid 状態!!! とりあえず rmdir で削除や cd で中に入ろうとするができない. もともと regular file なので, それはあたりまえかと思う. とにかく 644 にしようと思うが, 通常の mount した状態からは chmod が不可能だった. やはり debugfs の出番だ.
debugfs では chmod らしきものは "modify_inode" で, inode を持っている file に対して属性を変更できる (今回はなぜか 666 に変更)
すべては表示しないが, Mode のみ変更し, あとは enter をひたすら連打した.
debugfs: modify_inode file.201907170.img
Mode [044710] 666
User ID [46786]
Group ID [42450]
Size [49152]
Creation time [-251420407]
Modification time [-170039582]
Access time [987520066]
debugfs 上で再度 ls をすると, ? 状態はすでになくなっているが, その他の file も正しい uid/gid に変更されすっかり問題がなくなってしまった.
最初から fsck で file.201907170.img がおかしいと出ていたので, ひょっとすると残しておきたかった file.txt も問題はなかったのかもしれない.
しかし, すでに debugfs で rm 済みなので, もう帰ってこない. といっても, emacs の backup file があったので, そこから直近のものだけを書き加えてそれっぽく復旧しておいた.
fsckでいくらたっても終らない状態になった時は,
fsck で erorr になっている対象のみ, mount -o ro で確認や debugfs で確認し, 変更もしくは削除の対応をした方が良い. それを何度か繰替えせば, どの file も消さずに復旧できたかもしれない. とはいえ eSATA で HDD を外部接続しているのでそれが問題と思うので, HDD を 2つ購入し PC に内蔵し, 1つは現在の RAID の代り, もうひとつは rsync で一日一回 backup を検討している.
本来はオットマン状態の PC を机の上にするべきであるが, それは改善しない...
