Sep 11, 2010 15:19
При оформлении диска через gpart(gpt для 8.0) по схеме GPT можно использовать и gmirror и gconcat и gstripe, но нельзя в качестве провайдеров использовать raw-device, потому как метаданные записываются в последний сектор провайдера, какраз туда, где живет альтернативная копия GUID Partition.
Разжуём: gpart пишет альтернативную копию таблицы разделов в последние 33 блока,затем мы используем gmirror/gstripe/gconcat с сырыми(raw) дисками, ИХ метаданные пишутся в последний сектор сырых дисков, тем самым разрушая альтернативную копию guid partitions, записанную gpart.
После перезагрузки geom об этом сигнализирует и восстанавливает alternative guid partition, тем самым затирая метаданные от gmirror.
Пример:
# gpart create -s gpt ad0 (потом ad1)
gpart пишет в первые 33 блока: PMBR, GPT Header, инфо о Partitions и копию соответственно хранит в последних 33 блоках диска.
Теперь делаем gmirror/gconcat/gstripe для сырых дисков: ad0, ad1 так:
# gmirror label -v -b split -s 2048 data ad0 ad1 ...
# gconcat label -v data /dev/ad0 /dev/ad1 ...
# gstripe label -v -s 131072 data /dev/ad0 /dev/ad1 ...
Получаем проблему.
Но мы можем в качестве провайдера использовать не сырые диски, а партиции gpt, например: тогда метаданные будут сохраняться в последнем секторе партиции, а не raw диска.
gpart create -s gpt ad0 [ad1 ad2 ad3] // создаёт схему gpt в первых 34 секторах
gpart add -b 34 -t freebsd-ufs -l disk0 ad0 [ad1 ad2 ad3] // создаёт слайс на каждом из дисков и маркирует его (смотреть лейблы в /dev/gpt/)
gstripe label -v data /dev/gpt/disk0 /dev/gpt/disk1 /dev/gpt/disk2 /dev/gpt/disk3 // создаёт из указанных по лейблам партиций массив stripe с именем data (смотреть в /dev/stripe/)
newfs -U /dev/stripe/data //создаёт файловую систему на получившемся носителе
mount /dev/stripe/data /mnt
gpart,
hdd,
freebsd,
geom,
filesystem