web-dev-qa-db-ja.com

誤ってext4fsのサイズを16TBの制限を超えて変更しましたが、どのようにロールバックしますか？

次のコマンドを使用して、lvresizeを使用して15TBパーティションのサイズを拡大しようとしました。

lvresize --resizefs --size +1T /dev/vg0/mm

操作中にエラーは表示されませんでしたが、結果は一種の大惨事でした。ファイルが表示されなくなり、ドライブ全体が空になったようです。

syslogには次のエラーが含まれていました。

inode #2: block 31777: comm ls: bad entry in directory: inode out of bounds - offset=0(0), inode=2, rec_len=12, name_len=1

umountパーティションを管理し、それを修正するためにfsckを実行する計画でした。

$ fsck.ext4 -n /dev/mapper/vg0-mm
e2fsck 1.42.9 (4-Feb-2014)
Superblock has an invalid journal (inode 8).
Clear? no

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/mapper/vg0-mm

/dev/mapper/vg0-mm: ********** WARNING: Filesystem still has errors **********

$ fsck.ext4 -v /dev/mapper/vg0-mm
e2fsck 1.42.9 (4-Feb-2014)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***

Corruption found in superblock.  (inodes_count = 0).

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
     or
         e2fsck -b 32768 <device>

/dev/mapper/vg0-mm: ***** FILE SYSTEM WAS MODIFIED *****

OK、次に利用可能な代替スーパーブロックをリストしようとしています：

$ mke2fs -n  /dev/mapper/vg0-mm
mke2fs 1.42.9 (4-Feb-2014)
mke2fs: Size of device (0x100000000 blocks) /dev/mapper/vg0-mm too big to be expressed in 32 bits using a blocksize of 4096.

したがって、誤ってlvresizeで16TBの制限を超えてしまい、ext4fsで64ビット機能フラグが有効になっていないようです。

その後、サイズを16TBの制限以下に戻そうとしましたが、パーティションが（明らかに）汚れており、それで何もしたくないと考えるため、resize2fsも機能しません。

次に進むべき方向はありますか？サイズ変更を強制的に実行するか、64ビット機能フラグを有効にしようとしていますか？他に何か？

dumpe2fsは、他の情報とともにこれを表示します：

Inode count: 0
Block count: 4294967295
Block size: 4096

関連バージョン情報：

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
e2fsprogs version: 1.42.9-3ubuntu1.3 AMD64
Kernel version: 3.13.0-147-generic

更新：ソースコードをいくつか読んだ後、問題の根本原因が見つかりました： https://github.com/torvalds/linux/commit/4f2f76f751433908364ccff82f437a57d0e6e9b7

オーバーフローバグのおかげで、iノードカウントが0にリセットされた状況からどのように回復するかという疑問が残っています。

partitioningfilesystemlvmext4
2
Matti K

--resizefsオプションとextファイルシステムおよび最後から最後までの完全な16 TB大パーティションを使用したlvresizeに関する奇妙な動作は、2009年にすでに見られたようです：（ https://www.redhat.com/archives/ext3-users/2009-January/msg00003.html ）

「おそらく、このような境界条件に遭遇した場合、mkfsを1つのブロックから静かに切り落とす必要があります...」

終了クレジット？

スーパーブロックを手でハッキングすることで状況を修正することができました。最初に、開始状況のLVMスナップショットを作成しました。次に、詳細な調査のために、パーティションの最初の64kバイトをファイルにダンプしました。上記のバグにより、スーパーブロックの先頭にあるiノード数とブロック数の値が破損していました。 （ https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout ）

E2fsprogsのソースコードを調べると、iノード数とブロック数の値を書き込むことで、スーパーブロックの最大値の1つの小さいブロックグループ（32k）を試してみるといいことがわかりました。バイトは

00 80 ff ff 00 80 ff ff

そして、それらをパーティションに追加しました。

自己コンパイルされたe2fsprogsの最新バージョンでは、fsckが残りのエラーを修正できました。今はすべて大丈夫そうです。

1
matikka