web-dev-qa-db-ja.com

fsckは30TBext4パーティションで30日以上実行されており、マウントできません

Hwraid5に30TBのディスクパーティションがあるとします。 LVMが最上位で、ファイルシステムはext4です。 （99,9％のデータでいっぱいです。）さらに20TBを追加し、パーティションとファイルシステムのサイズを変更したいと思いました。サイズを変更する前に、最初にFSCKを実行することを主張しました。 1週間以上実行されているため、キャンセルしましたが、パーティションをマウントできませんでした。最初にFSCKが必要でした。それでまた始めました。

fsck.ext4 -v -C 0 /dev/vgname/lvname
e2fsck 1.44.3 (10-July-2018)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

Resize inode not valid.  Recreate<y>? yes

そして、31日が経過し、それがまだ実行されているので、1つのCPUコアを100％占有しています。

でそれを見るとき strace、これは私が見るものです：

strace -p 3174
strace: Process 3174 attached
strace: [ Process PID=3174 runs in x32 mode. ]
strace: [ Process PID=3174 runs in 64 bit mode. ]
pread64(4, "\375\210\372\374\360\10\375=$\375\254\221\375\334\361\375l?\376?U\376\24?\376\27\351\375:\305\375\217"..., 4096, 2447145635840) = 4096
mremap(0x7fa5e3565000, 208764928, 208769024, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "\0\305\7\0\321\376\377q\367\377Q\364\377\371\361\377H\355\377\323\346\377\271\337\377\275\332\377J\326\377\16"..., 4096, 1724118507520) = 4096
pread64(4, "x\377\371p\377_b\377\177W\377\35[\377\223N\377\226[\377&h\377QS\377\203O\377sT\377"..., 4096, 3443764559872) = 4096
pread64(4, "\377\263\371\377\375\355\377\363\6\0\367\356\377\326\21\0\350\353\377?\30\0\242\345\377\375\26\0|\344\377D"..., 4096, 6956990242816) = 4096
pread64(4, "\0\3201\273\0\24)\273\0\34=\273\0\336/\273\0\316/\273\0\3167\273\0\220*\273\0\3569\273"..., 4096, 8609803698176) = 4096
pread64(4, "o\f\257\205\16\377=\20\367\270\21\376\312\22\252R\0234\227\23\242\303\23\234\343\23Z\376\23LI\24"..., 4096, 1755810463744) = 4096
mremap(0x7fa5e3565000, 208769024, 208773120, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "\22\0\\\2\0\347\352\377\347\303\377?\250\3776\224\377Ht\377\17W\377\245G\377\5G\377}[\377"..., 4096, 14672424988672) = 4096
mremap(0x7fa5e3565000, 208773120, 208777216, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "\255\2\202)#m\22\5N\244F\210\221\20+.\21\5\352\306\344\220\25\3567\250\16\323\2\247P\352"..., 4096, 16981972766720) = 4096
mremap(0x7fa5e3565000, 208777216, 208781312, MREMAP_MAYMOVE) = 0x7fa5e3565000
pread64(4, "M\0\205N\0KO\0\4P\0\221P\0)Q\0\336Q\0\204R\0SS\0\tT\0\371T\0"..., 4096, 833004105728) = 4096

新しいラインは30〜60秒ごとに作成されるため、めったにありません。誰かが私に何が起こっているのか手がかりを与えることができますか、そして私はデータに再びアクセスできるようになるまで待つべきですか、それとも何をすべきですか？

linuxfilesystemsfsck
6
G Grosschmid

提案ありがとうございます。 fsckを実行する前に、ディスクはすでにマウント解除されていました。 antony_sebastianから応答の提案を受け取った後、これを試すためにサーバーにログインし、画面コマンドを再開し、fsckは入力を待っていました。驚いたことに、33日間のチェックの後、30TBディスクの処理が終了しました。すべての修正可能な問題に「はい」と応答すると、データは元に戻りましたが、すべてが「Lost + found」の下に移動し、ルートディレクトリツリーのフォルダ名が失われました。それ以外は、データは無傷で問題ありませんでした。

提案と助けをありがとう、すべて！

1
G Grosschmid

次の手順を実行してください。

最初にディスクをアンマウントし、

umount/dev/disk

Linuxは、すべてのファイルシステムでスーパーブロックの複数の冗長コピーを維持しています。スーパーブロックメタデータの冗長コピーを使用してデータを回復できます。

dumpe2fs/dev/disk | grepスーパーブロック

使用できる代替スーパーブロックが表示されます。

fsck -y -b blockid/dev/disk

損傷したすべてのスーパーブロックに対してこの手順を繰り返します。つまり、スーパーブロックをバックアップスーパーブロックに置き換えます。

ディスクをマウントして、再度使用できます

0
antony_sebastian