☰

mdadm RAID5の作成（最初に3つのディスクを使用）

tag-icon • tag-icon filesystems lvm btrfs luks raid5
mdadm RAID5の作成（最初に3つのディスクを使用）

BTRFSファイルシステムの内部には、LUKS2暗号化の上にLVM Raid5構成の3つの10Tb HDDが設定されています。

ストレージが不足して16TB HDD（10TBより安い）を追加し、LVMの物理ボリュームとして追加した後、ボリュームグループに追加し、LVMがRAIDのサイズを変更できるように再同期を実行しました。 btrfs パーティションのサイズを最大サイズに調整しました。

btrfsサイズを書いた直後にdmesgでエラーが発生し始めたことがわかりました。

[53034.840728] btrfs_dev_stat_print_on_error: 299 callbacks suppressed
[53034.840731] BTRFS error (device dm-15): bdev /dev/mapper/data errs: wr 807, rd 0, flush 0, corrupt 0, gen 0
[53034.841289] BTRFS error (device dm-15): bdev /dev/mapper/data errs: wr 808, rd 0, flush 0, corrupt 0, gen 0
[53034.844993] BTRFS error (device dm-15): bdev /dev/mapper/data errs: wr 809, rd 0, flush 0, corrupt 0, gen 0
[53034.845893] BTRFS error (device dm-15): bdev /dev/mapper/data errs: wr 810, rd 0, flush 0, corrupt 0, gen 0
[53034.846154] BTRFS error (device dm-15): bdev /dev/mapper/data errs: wr 811, rd 0, flush 0, corrupt 0, gen 0

仮想マシンの他のコンピュータで試したため、ハードウェアの問題を排除できます。 dmesgの問題は、ファイルシステムに大きなファイル（400Mb）を書き込むときに発生しますが、テキストファイルなどのファイルは書きません。次の攻撃では、あるファイルから別のファイルにコピーした後もチェックサムが正しくありません。

gallifrey raid5 # dd if=/dev/urandom of=original.img bs=40M count=100
0+100 records in
0+100 records out
3355443100 bytes (3.4 GB, 3.1 GiB) copied, 54.0163 s, 62.1 MB/s
gallifrey raid5 # cp original.img copy.img
gallifrey raid5 # md5sum original.img copy.img            
29867131c09cc5a6e8958b2eba5db4c9  original.img
59511b99494dd4f7cf1432b19f4548c4  copy.img

gallifrey raid5 # btrfs device stats /mnt/raid5 
[/dev/mapper/data].write_io_errs    811
[/dev/mapper/data].read_io_errs     0
[/dev/mapper/data].flush_io_errs    0
[/dev/mapper/data].corruption_errs  0
[/dev/mapper/data].generation_errs  0

lvm raid全体を再同期し、smartctlチェックを複数回実行しましたが（ハードウェアの問題ではありませんが、まだ）エラーは返されませんbtrfs scrub start -B /mnt/raid5。btrfs check -p --force /dev/mapper/data

カーネル5.15.11と5.10.27で発生します。

LVMバージョン：

gallifrey raid5 # lvm version  
  LVM version:     2.02.188(2) (2021-05-07)
  Library version: 1.02.172 (2021-05-07)
  Driver version:  4.45.0

私の目標は、将来のドライブの書き込みが破損することなく、すでに破損しているファイルを削除できることです。しかし、良いファイルは保存したり、少なくとも削除したくありません。

btrfsのマニュアルページでは、これはwrite_io_errs次のブロックデバイスの書き込みが失敗したことを意味します。私の場合、lvmおよび/またはluks2が問題であることを意味します。

提案があるか、追加情報が必要ですか？

乾杯

答え1

この問題の根本原因が見つからなかったので、LVMを完全に廃棄してmdadmに置き換えることにしました。最初の試みで素晴らしい仕事をしました。

mdadm RAID5の作成（最初に3つのディスクを使用）

  1. 3つのディスクで作成されます（したがって、raid-devices = 3）：

mdadm --create mediaraid --level=raid5 --raid-devices=3 /dev/sda /dev/sdb /dev/sde

  1. （オプション）どの速度（ディスクIOではなくメモリ速度）でどの暗号化が利用可能かを確認します。

cryptsetup benchmark /dev/md/mediaraid

  1. オプションでRAID全体を暗号化します（これらの構成では、各ディスクを個別に復号化する必要はありません。RAID全体に対して1つのパスワード）：

cryptsetup luksFormat --hash sha512 --cipher aes-xts-plain64 --key-size 512 /dev/md/mediaraid

  1. LUKSデバイスを開きます（フォーマットに必要）。

cryptsetup luksOpen /dev/md/mediaraid

  1. btrfsを使用したRAIDフォーマット：

mkfs.btrfs /dev/mapper/data -f

1つのディスクと基本的なmdadm RAID5を介してbtrfsファイルシステムを拡張/拡張

前提条件：ファイルシステムがマウントされず、LUKSデバイスが閉じています。

umount /mnt/raid5 && cryptsetup close /dev/mapper/data

  1. /dev/sdc (ドライブと交換) を mdadm にスペアとして追加します。

mdadm --add /dev/md/mediaraid /dev/sdc

  1. 表示されていることを確認します（下部に表示され、スペアディスクであることを示します）。

mdadm --detail /dev/md/mediaraid

メモ:次のステップでは、RAIDの再構成を開始し、状況が現実化されました。私の10TBドライブは3つから4つのディスクに再構成して同期するのに約25〜30時間かかりました。 respahe中に再起動するのが安全かどうかはわかりません。しかし、お勧めしないか、少なくとも仮想マシンで試してみましょう。

  1. RAIDをディスク数に増やします（ほとんどの場合、ここにディスクの総数を書き込もうとしています（3 + 1 = 4）。4台のドライブが利用可能で、そのうち4台をすべて使いたい）。

mdadm --grow --raid-devices=4 /dev/md/mediaraid

  1. 外観の変更の進行状況を監視します（最初の方が良い）。

cat /proc/mdstatまたはmdadm --detail /dev/md/mediaraid

形状の変更が完了した後：

  1. またはLUKSを使用している場合RAID 復号化 - そうでない場合は、次の手順に進みます。

cryptsetup luksOpen /dev/md/mediaraid data

  1. btrfsファイルシステムのマウント：

mount /dev/mapper/data /mnt/raid5

  1. btrfsファイルシステムを最大または必要に応じて拡張します。

btrfs filesystem resize max /mnt/raid5

  1. おそらく必要はありませんが、btrfsファイルシステムのサイズを変更した後、すべてを削除して再インストールしました。

umount /mnt/raid5 && mount /dev/maper/data /mnt/raid5

完璧。

答え2

raid5+dm-crypt+btrfs に関する警告です。

mdraidはlvm raidよりはるかに優れています。しかし、raid5は最悪のraidレベルです。

Raid5は書き込み性能と堅牢性が不便です。劣化モードではさらに悪化します。

btrfs自体は冗長であるため、raid5のbtrfsは有線として使用されます。

しかし、btrfsは有線冗長動作のために脆弱で信頼できません。

したがって、raid5 + dm-crypt + btrfsはよりひどい設定です。書き込み性能が最悪で、最終的にデータが失われます。

ディスクに障害が発生すると、raid5で10TBの同期が無限大になります。または、バグや停電によってオペレーティングシステムがクラッシュした場合、btrfs自体が破損したり、dm-crypt、raid5（オペレーティングシステムのページキャッシュ、ディスクハードウェアキャッシュ、raid書き込みの脆弱性）によって破損したりします。

btrfsに何の問題がありますか？

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/

答え3

問題はbtrfs-progsのバグかもしれませんか？

https://lore.kernel.org/linux-btrfs/[Eメール保護]/

関連情報