fstab의 UUID + fstab에서 UUID를 구성할 수 없는 상황

fstab의 UUID + fstab에서 UUID를 구성할 수 없는 상황

토론 - Redhat Linux 시스템이 있습니다. 제 질문은 /etc/fstab 파일의 UUID 구성에 관한 것입니다. 이 경우 UUID는 운영 체제에 위험을 가져옵니다.

내가 아는 한, 소프트웨어 RAID1을 사용하는 경우 /etc/fstab에서 UUID를 사용할 수 없습니다.

왜?RAID 볼륨 자체와 미러의 첫 번째 요소가 동일한 파일 시스템 UUID를 갖는 것으로 나타나기 때문입니다. 이미지가 손상되었거나 다른 이유로 인해 md 장치가 부팅 시 작동되지 않는 경우 시스템은 임의의 기본 디스크를 마운트하여 이미지를 손상시킵니다.

그래서 내 질문은

RAID 레벨(번호)은 무엇입니까?기필코 아니다UUID가 fstab에 있나요?

공격 수준 정보 -https://en.wikipedia.org/wiki/Standard_RAID_levels

답변1

우리는 ArchLinux와 mdadm에 대한 테스트를 계속할 것입니다. 그러나 우선 파티션 기반 배열에서는 구성원 파티션에 고유한 UUID가 있으므로 이는 중요하지 않습니다. 따라서 이론적으로 이는 전체 디스크 구성원에만 적용됩니다.

요약: 이는 오래된 메타데이터 청크의 경우에도 실제로 문제가 되지 않습니다. 이것은 내가 모르는 오래된 소프트웨어의 버그일 수 있습니다. 그러나 최신 ArchLinux에는 영향을 미치지 않습니다.

#uname -sr
Linux 4.14.7-1-ARCH

#modprobe raid1

#mdadm --create --verbose /dev/md0 --metadata 0.9 --level=mirror --raid-devices=2 /dev/sdb /dev/sdd
mdadm: size set to 102336K
mdadm: array /dev/md0 started.

#cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd[1] sdb[0]
102336 blocks [2/2] [UU]

unused devices: <none>

#mdadm --detail --scan >> /etc/mdadm.conf

fdisk /dev/md0
lsblk /dev/md0
NAME      MAJ:MIN RM   SIZE  RO TYPE MOUNTPOINT
sdb         8:16   0    100M  0 disk
└─md0       9:0    0    100M  0 raid1
  └─md0p1 259:0    0   98.9M  0 md 
sdd         8:48   0    100M  0 disk
└─md0       9:0    0    100M  0 raid1
  └─md0p1 259:0    0   98.9M  0 md 
md0         8:0    0    100M  0 raid1
└─sda2      8:2    0   98.9M  0 md

mdstat -> [UU]

#blkid /dev/md0
/dev/md0: PTUUID="d49d8666-e580-8244-8c82-2bc325157e66" PTTYPE="gpt"
#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
#blkid /dev/sdb
/dev/sdb: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

#mkfs.ext4 /dev/md0p1
mke2fs 1.43.7 (16-Oct-2017)
creating filesystem with 101292 1k blocks and 25376 inodes
Filesystem UUID: 652bcf77-fe47-416e-952c-bbOa76a78407
Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done 

#mount /dev/md0p1 /mnt

#lsblk -o NAME,UUID,MOUNTPOINT /dev/sdb /dev/sdd
NAME      UUID                                 MOUNTPOINT
sdb       b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
  └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt
sdd       b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
  └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt

여태까지는 그런대로 잘됐다. 이는 구성원 장치를 RAID 장치로 올바르게 식별할 뿐만 아니라 두 개의 일치하는 파티션 수준 UUID도 갖습니다. 실제로 이는 동일한 컨테이너 장치 md0의 일부이며 동일한 마운트 지점을 나열합니다. sdd 또는 sdb의 일반 파티션 컨테이너는 나열되지 않습니다. md0 장치 자체에는 UUID가 없습니다. 오직 그 구성원만이 UUID를 가지며, 그들의 UUID는 실제로 동일합니다.

#echo "UUID=652bcf77-fe47-416e-952c-bbOa76a78407 /mnt ext4 rw,relatime,data=ordered 0 2" >> /etc/fstab
umount /mnt
mount /mnt
cd /mnt
fallocate -l 50MiB data

mdstat -> [UU]

raid 구성원의 파일 시스템 UUID를 요청하고 있으므로 이제 mdadm을 실행하지 않고 시스템을 실행해 보겠습니다.

#cd
#umount /mnt
#mdadm --stop /dev/md0
mdadm: stopped /dev/md0
#lsblk /dev/sdb /dev/sdd
NAME MAJ:MIN RM  SIZE  RO TYPE MOUNTPOINT
sdb    8:16   0  100M  0 disk
sdd    8:48   0  100M  0 disk

이제 시스템은 파티션 테이블이 없고 따라서 컨테이너가 아니기 때문에 이것이 올바른 원시 디스크라고 생각합니다. 그러나 그것이 무엇인지 묻는다면:

#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

마운트하려고 하면 여전히 linux_raid_member입니다.

#mount /dev/sdd /mnt
mount /mnt: unknown filesystem type "linux raid member"

어때요?

#mount /mnt
mount: /mnt can't find UUID=652bcf77-fe47-416e-952c-bbOa76a78407

sdd는 컨테이너가 아니므로 조사할 파일 시스템이 없기 때문에 이는 의미가 있습니다. 하지만 내가 실행하면 :

#mdadm --assemble --scan && mount /mnt
mdadm: /dev/md0 has been started with 2 drives.

다시 중지하고 mdadm.conf를 삭제하면 다음과 같습니다.

#umount /mnt && mdadm --stop /dev/md0
#modprobe -r raid1
#rm /etc/mdadm.conf
#modprobe raid1
#mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 2 drives.

md0 장치 이름에 대한 내 구성은 더 이상 적용되지 않으며 자동으로 /dev/md/0에 생성됩니다. 이제 재부팅하고 systemd/Linux가 fstab으로 무엇을 하는지 살펴보겠습니다.

#mdadm --stop /dev/md/0
mdadm: stopped /dev/md/0
#systemctl reboot


#dmesg | grep md0
[  14.550231] md/raidl:md0: active with 2 out of 2 mirrors
[  14.550261] md0: detected capacity change from 0 to 104792064
[  14.836905]  md0: p1
[  16.909057] EXT4-fs (md0p1): mounted filesystem with ordered data mode. Opts: data=ordered

#lsblk /dev/md0
NAME      MAJ:MIN RM SIZE RO TYPE  MOUNTPOINT
md0       9:0     0  100M 0  raidl 
└─md0p1 259:0     0 98.9M 0  md    /mnt

다시 raid=noautoDetect 커널 매개변수를 사용하십시오. 그러면 모든 RAID 및 모든 슈퍼블록/메타데이터 버전 등을 자동으로 감지하지 못하는 Linux 버전도 에뮬레이션됩니다. 하지만 fstab에서 요청했기 때문에 여전히 raid를 마운트하고 mod raid1을 강제로 로드합니다. 이제 modprobe.blacklist=raid1을 사용하여 다시 블랙리스트에 등록해 보겠습니다.

여기에 이미지 설명을 입력하세요.

알았어, 무슨 일이야? :

여기에 이미지 설명을 입력하세요.

따라서 Linux는 RAID 지원 기능이 없더라도 이것이 RAID 유형 장치라는 것을 알고 있습니다. 마운트하려고 할 때 raid 장치를 올바르게 감지하고 fstab을 사용할 때 파일 시스템 슈퍼 블록에 있음에도 불구하고 UUID를 찾을 수 없습니다.

그리고 다시! fstab 또는 mdadm에는 정보가 없습니다.

#mount /dev/sdd /mnt
mount: /mnt: unknown filesystem type "linux_raid_member".

여기서 중요한 점은 Linux 프로빙이 똑똑하다는 것뿐만이 아니라고 생각합니다. fdisk Warm과 같은 도구를 사용하는 것 외에도 파티션 테이블 영역은 추가 정보로 채워집니다. 이 오류가 구성원 디스크 중 하나의 파일 시스템 UUID가 되도록 하려면 정말 열심히 노력해야 합니다.

답변2

이전 답변에 따르면 다음을 수행하면 걱정 없이 모든 RAID "레벨"에서 UUID를 사용할 수 있습니다.

  • mdadm 메타데이터 v0.9 또는 v1.0을 사용하지 마십시오(대신 v1.1 또는 1.2 사용).
  • 파일 시스템이 아닌 MD 어레이와 연관된 UUID를 사용하십시오. 물론, FS를 소프트웨어 레이드에서 다른 장치로 옮기면 재구성이 필요하겠지만, 아마 그런 걱정을 할 이유는 없을 것입니다.

이 경우 fstab에서 UUID를 구성하는 데 문제가 발생합니다.

관련 정보