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개 사용)
- 세 개의 디스크로 생성됨(따라서 raid-devices = 3):
mdadm --create mediaraid --level=raid5 --raid-devices=3 /dev/sda /dev/sdb /dev/sde
- (선택 사항) 어떤 속도(디스크 IO가 아닌 메모리 속도)에서 어떤 암호화를 사용할 수 있는지 확인합니다.
cryptsetup benchmark /dev/md/mediaraid
- 선택적으로 전체 RAID를 암호화합니다(이러한 구성에서는 각 디스크를 개별적으로 해독할 필요가 없습니다. 전체 RAID에 대해 하나의 비밀번호):
cryptsetup luksFormat --hash sha512 --cipher aes-xts-plain64 --key-size 512 /dev/md/mediaraid
- LUKS 장치를 엽니다(포맷에 필요).
cryptsetup luksOpen /dev/md/mediaraid
- btrfs를 사용하여 RAID 포맷:
mkfs.btrfs /dev/mapper/data -f
1개의 디스크와 기본 mdadm RAID5를 통해 btrfs 파일 시스템 확장/확장
전제 조건: 파일 시스템이 마운트되지 않고 LUKS 장치가 닫혀 있습니다.
umount /mnt/raid5 && cryptsetup close /dev/mapper/data
- /dev/sdc(드라이브로 교체)를 mdadm에 예비로 추가합니다.
mdadm --add /dev/md/mediaraid /dev/sdc
- 표시되는지 확인합니다(하단에 표시되어 예비 디스크임을 나타냄).
mdadm --detail /dev/md/mediaraid
노트:다음 단계에서는 RAID 재구성을 시작하고 상황이 현실화되었습니다. 내 10TB 드라이브는 3개에서 4개의 디스크로 재구성하고 동기화하는 데 약 25~30시간이 걸렸습니다. respahe 중에 재부팅하는 것이 안전한지 잘 모르겠습니다. 하지만 권장하지 않거나 적어도 가상 머신에서 시도해 보도록 하겠습니다.
- RAID를 디스크 수로 늘립니다(대부분의 경우 여기에 총 디스크 수를 기록하려고 합니다(3 + 1 = 4). 이제 4개의 드라이브를 사용할 수 있으며 그 중 4개를 모두 사용하려고 합니다).
mdadm --grow --raid-devices=4 /dev/md/mediaraid
- 모양 변경 진행 상황을 모니터링합니다(첫 번째 것이 더 좋음).
cat /proc/mdstat
또는mdadm --detail /dev/md/mediaraid
모양 변경을 완료한 후:
- 또는 LUKS를 사용하는 경우RAID 암호 해독 - 그렇지 않은 경우 다음 단계를 계속합니다.
cryptsetup luksOpen /dev/md/mediaraid data
- btrfs 파일 시스템 마운트:
mount /dev/mapper/data /mnt/raid5
- btrfs 파일 시스템을 최대 또는 원하는 대로 확장하십시오.
btrfs filesystem resize max /mnt/raid5
- 아마도 필요하지는 않지만 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의 버그일 수 있습니까?