web-dev-qa-db-ja.com

サイズ変更/縮小後のBTRFSスーパーブロックエラーを修正する方法（BTRFS：bytenr 274877906944のスーパーバッファーヘッドを取得できませんでした）

2 500 GBHDDを搭載したBTRFSRAID1アレイ、エラーなし。これはルートファイルシステムであるため、各ドライブには3つのパーティションがあります：1 =/boot（ext4）、2 = /（btrfs）、3（swap）

/ bootがbtrfsファイルシステムの場合（新しいカーネルはインストールされていますが、grub構成は更新されていません）、カーネルのアップグレードが常に機能するとは限らないため、/ bootはext4です。

現在、このミラーはより小さなドライブに移動され、新しいドライブは120 GBであるため、btrfsファイルシステムのサイズを変更する必要があります。両方のbtrfsパーティションのサイズ変更は、たとえばGPartedを使用して実行できます。サイズ変更後、パーティション情報を含むMBRを古い500GBドライブから新しい120GBドライブにコピーできます（dd if=/dev/sda of=/dev/sdb bs=512 count=1）、およびbtrfsパーティション（dd if=/dev/sda2 of=/dev/sdb2）。 （120 GB内に収まるように移動する必要があるスワップパーティションを無視します。）

システムは起動し、新しい120 GBドライブで問題は発生しませんが、次の1つのエラーメッセージがログに記録されます（dmesg）。

BTRFS：bytenr274877906944のスーパーバッファーヘッドを取得できませんでした

そして、スクラブは「スーパー」エラーを見つけます（ただしデータエラーはありません）：

「エラーの詳細：super = 1」

このエラーによるデータ破損のリスクはありますか？
これはどのように修正できますか？

274877906944は256GB、古いbtrfsパーティションは> 256 GB、新しいパーティションは<256 GBであるため、システムは256 GBのスーパーブロックを探しているようです。

linuxhard-diskddbtrfssuperblock
3
basic6

警告：GPartedを使用してマルチデバイスBTRFSファイルシステムのサイズを変更しないでください！

データ損失が発生する可能性があります！

GPartedが原因のようです。どうやら、マルチデバイスbtrfsファイルシステムのサイズを変更する方法がわからず、btrfs filesystem resizeを実行するだけですが、resize 1:49gとresize 2:49gを使用して各デバイスを処理しません。

これはbtrfs filesystem showが言ったことです：

Total devices 2 FS bytes used 40.95GiB
devid    1 size 50.00GiB used 43.03GiB path /dev/sda2
devid    2 size 439.45GiB used 43.03GiB path /dev/sdb2

明らかに、GPartedは2番目のデバイスのファイルシステムのサイズを変更していないため、Btrfsはそれが500GBのファイルシステムであると考えています。

ある時点で、Btrfsはディスクの外部でデータの読み取り/書き込みを試みていたでしょう。これは破損を引き起こし、ファイルシステム全体を役に立たなくする可能性さえあります。

修正

最初に、ライブシステムを起動して、システムが存在するパーティションよりも大きいファイルシステムで実行されている間の損傷のリスクを軽減しました。

ファイルシステムをマウントします。

mount /dev/sda2 /mnt/tmp

最初に、丸め誤差を回避するために、2番目のデバイスを50 GB-1 GB = 49GBに縮小します。

btrfs filesystem resize 2:49g /mnt/tmp

50GBのパーティションを満たすようにサイズを変更します。

btrfs filesystem resize 2:max /mnt/tmp

btrfs filesystem showを確認してください。両方のデバイスのサイズが適切である必要があります。

devid    1 size 50.00GiB used 43.03GiB path /dev/sda2
devid    2 size 50.00GiB used 43.03GiB path /dev/sdb2

アンマウントして再起動すると、エラーはなくなります。

システムがその悪い状態で実行されている間に何も損傷していなければ、ファイルシステムは正常であるはずです。

（これを修正するのを手伝ってくれたdarklingに感謝します。）

4
basic6