A uz se da vytvorit virtualni zarizeni reprezentujci pole (jako u MD) a obejit tim bug kdy moutovane zarizeni v poli neni dostupne ? Nebo se stale stava ze kdyz vytahnu/umre z RAID1 disk ktery se zrovna pouziva pro mount pole tak selze boot ? Popripadne bude vse vypadat podivne a budu mit fantom drive v OS kdyz jej vytahnu za behu ? Nebo je to nejak jinak resene ? Protoze tohle byl u RAID s btrfs kdyz jsem jej testoval epic fail.
Radeji jsem sveril sva data EXT4 a MD...
No jasne ze se pouziva UUID ale to nic neresi, me jde o to co se stane kdyz napr tomu disku jehoz UUID pouzivam pro mount / odejde elektronika ? pak disk proste zmizi a ja NENABOOTUJU protoze v tu chvili vlastne neexistuje cele pole protoze btrfs prinasi tu "uzasnou super vyhodu" kde staci mountnout libovolny disk z pole a pole se sestavi a pripoji...
Priklad: Ja tu mam RAID 1 z 4x2TiB disku:
Disk 1 UUID: aaa-aaa
Disk 2 UUID: bbb-bbb
Disk 3 UUID: ccc-ccc
Disk 4 UUID: ddd-ddd
Vytvorim na nich RAID 1 diky BTRFS
Disk 1 dam dle UUID (aaa-aaa) do fstab moutnu jako /home:
UUID=aaa-aaa /home btrfs rw,relatime,data=ordered 0 2
Restnu a vsechno pojede super truper...
Test 1: A pak vyrvu disk aaa-aaa z diskoveho pole za behu OS a vse zacne vypadat podivne! Vyzkousejte si to... disk zmizi i s UUID, moutpoint existuje a funguje ale OS neni schopen mi rict kam vede -> fail
Test 2: Vyrvu disk aaa-aaa za vypnuteho stavu (disky casto chcipaji pri rebootech) no a hadejte co se stane... OFC selze mount toho disku protoze neexistuje a je po bootu! :-D Aby clovek nabootoval tak musi vratit aaa-aaa do diskoveho pole protoze UUID a nebo nejakym zpusobem zmenit UUID ve fstab na jiny disk v poli
No proste uzasne navrzene btrfs muze jit s RAID do haje dokud tohle nejak nevyresi...
Tak to ani omylem, UUID kazdeho oddilu bylo uplne jine... proto se taky ptam, zda li je to opravene nebo ne testoval jsem to tak pred 2 mesici na aktualnim ubuntu.
Kdyz jsem odpojil jeden disk z diskoveho pole tak jsem skoncil na tom ze UUID nelze najit pri bootu a funkcni RAID 1 to byl.
Takze mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sde1 proste failnul zmenit UUID ? nebo to mam menit ja rucne ? Jel jsem podle https://btrfs.wiki.kernel.org/index.php/UseCases ... nikde zadnej notice nic
Ale uz ten fail konecne zacina davat smysl... (a cely reseni toho RAID mountu) tak se k tomu jeste vratim na aktualnim archu, alespon ted vim jak to pripadne vyresit protoze tehdy google nebyl nijak napomocen, jen jsem nasel lidi co meli stejny problem a jedina rada byla pouzit /dev nazvy a doufat ze se na misto puvodniho disku napasuje jiny disk z pole :-D Tak to me tehdy trochu nakrklo
Pro UUID oddílů se používá PARTUUID=, pro UUID filesystému UUID=. Zatím jsem neviděl distribuci, která by používala to první, protože UUID oddílů vyžadují GPT a to stále není výchozí (na MBR nemají oddíly UUID). S UUID= boot funguje, i když vytáhnu první disk, protože je na všech discích stejný.
Tento vikend som sa s tym akurat hral. Ked vytvoris mirror na btrfs, dostanes pseudo UUID ktore zastresuje ten mirror a vsetky disky v nom. Dokonca to mozes spravit tak, ze spravis jeden btrfs disk, nahras nan data a potom pridas dalsi a nechas ich vybalansovat. Ked som vyrval jeden disk, tak to v pohode nabootovalo. Nasledne toto UUID pouzijes v fstab:
[root@anduril mirror]# btrfs filesystem show
Label: 'Mirror' uuid: e8cc237c-38fe-4f72-bebe-784224243cba
Total devices 2 FS bytes used 1.56TiB
devid 1 size 1.82TiB used 1.56TiB path /dev/sdb
devid 2 size 1.82TiB used 1.56TiB path /dev/sdd
Label: 'NonRaid' uuid: 570e554a-44db-4f89-a790-4b2fa5dbe52e
Total devices 1 FS bytes used 1.11GiB
devid 1 size 1.82TiB used 5.02GiB path /dev/sdc
[root@anduril mirror]# cat /etc/fstab
UUID=e8cc237c-38fe-4f72-bebe-784224243cba /mnt/mirror btrfs defaults 0 0
UUID=570e554a-44db-4f89-a790-4b2fa5dbe52e /mnt/nonraid0 btrfs defaults 0 0