Не все йогурты одинаково полезны
2012-11-04 11:04 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurZFS в качестве корневой загрузочной файловой системы FreeBSD 9 не так хороша, как могла бы быть:
Начинается всё вроде бы неплохо. Первый сектор GPT-размеченного жёсткого диска (любого из двух) получает управление от BIOS'а и ищет в GPT-таблице раздел с UUIDом типа "freebsd-boot". Это маленький раздел, который загружается в память целиком и получает управление. Там находится более толстый загрузчик (gptzfsboot), который сканирует GPT-таблицу разделов в поисках раздела с UUIDом типа "freebsd-zfs". Далее толстый загрузчик монтирует этот раздел в режиме readonly, и поскольку ZFS всегда консистентна на диске, журнал не нужен: из раздела считывается /boot/loader.rc и зависимые файлы, далее /boot/modules/kernel и зависимые модули, а также мелкий файлик под названием /boot/zfs/zpool.cache, который позволяет ядру после загрузки выстроить дерево GEOM-провайдеров в правильном порядке, чтобы собрать ZFS пул (в кэше хранятся GPT labels, тип RAIDа и т.п.).
Если этот ZFSовский недореестр /boot/zfs/zpool.cache устарел из-за апгрейда ядра ОС, рассыпался (он таки имеет бинарный формат — дотянулся проклятый Баллмер), потерялся при перекомпиляции/обновлении ядра, перестал соответствовать пулу zfs по корневым аттрибутам типа txg или phys_path или guid или ещё какой-то хуйне, которую додумались туда засунуть погромисты сана перед окончательным погромом сана, тогда ядро бзди не загружается.
Если у нас есть физический доступ к консоли, али какой-нибудь навороченный KVM-over-IP, мы видим жалобу на невозможность монтирования корневой файловой системы.
Trying to mount root from zfs:zroot []...
Mounting from zfs:zroot failed with error 2
А если у нас удалённый дедик, доступный только по ssh, то всё гораздо хуже...
И пофиг, что загрузчик видит пул и может достать из него свои конфиги, ядро и модули. И пофиг, что раздела всего два и они помечены известным UUIDом в GPT-таблицах обоих дисков. И пофиг, что все метаданные есть внутри этих разделов на диске, ведь "zfs import -f zroot" нормально монтирует пул при загрузке с аварийно-восстановительного CD! Ядро не может найти корневую ФС и всё тут!
Почему-то предыдущая в истории FreeBSD конструкция для подобной задачи (gmirror + ufs + softupdates) справляется с этой ситуацией на ура: загрузчик отрабатывает так же, далее в ядре, поскольку все метаданные хранятся в последнем секторе разделов (и не мешают ufs'у, который по своему размеру в суперблоке на 1 сектор меньше размера раздела в GPT), geom собирает зеркало автоматически, далее корневая ФС монтируется из ufs:/dev/mirror/MirrorName безо всяких бинарных кэшей, реестров и прочего подобного говна. Softupdates вместо журналирования нужны потому, что для корневой загрузочной ФС некому проиграть журнал до начала загрузки ядра. Эта конструкция проигрывает ZFS в том, что у неё происходят утечки дисковой памяти при внеплановых перезагрузках (лечится фоновым fsck в автозагрузке); также нету bit rot prevention и снэпшотов; ну и скорость проигрывает. Однако если вынести основной набор данных на ZFS, а только корневую/загрузочную ФС оставить на UFS, то выходит вполне нормально.
Кто-то скажет, что для ценителей ZFS есть Solaris, однако судя по докам оракла, на соляре та же петрушка: http://docs.oracle.com/cd/E19082-01/817-2271/gbbwc/index.html
Выводы: FreeBSD остро нуждается в патче, который позволит ядру загружаться с ZFS-пула вообще без файла zpool.cache, только по имени пула. Я точно знаю, что это возможно, ведь именно так монтируются ZFS-пулы при выполнении zpool import -f в контексте аварийно-спасательного CD. А пока для корневой ФС юзаем gmirror + ufs + softupdates.
Начинается всё вроде бы неплохо. Первый сектор GPT-размеченного жёсткого диска (любого из двух) получает управление от BIOS'а и ищет в GPT-таблице раздел с UUIDом типа "freebsd-boot". Это маленький раздел, который загружается в память целиком и получает управление. Там находится более толстый загрузчик (gptzfsboot), который сканирует GPT-таблицу разделов в поисках раздела с UUIDом типа "freebsd-zfs". Далее толстый загрузчик монтирует этот раздел в режиме readonly, и поскольку ZFS всегда консистентна на диске, журнал не нужен: из раздела считывается /boot/loader.rc и зависимые файлы, далее /boot/modules/kernel и зависимые модули, а также мелкий файлик под названием /boot/zfs/zpool.cache, который позволяет ядру после загрузки выстроить дерево GEOM-провайдеров в правильном порядке, чтобы собрать ZFS пул (в кэше хранятся GPT labels, тип RAIDа и т.п.).
Если этот ZFSовский недореестр /boot/zfs/zpool.cache устарел из-за апгрейда ядра ОС, рассыпался (он таки имеет бинарный формат — дотянулся проклятый Баллмер), потерялся при перекомпиляции/обновлении ядра, перестал соответствовать пулу zfs по корневым аттрибутам типа txg или phys_path или guid или ещё какой-то хуйне, которую додумались туда засунуть погромисты сана перед окончательным погромом сана, тогда ядро бзди не загружается.
Если у нас есть физический доступ к консоли, али какой-нибудь навороченный KVM-over-IP, мы видим жалобу на невозможность монтирования корневой файловой системы.
Trying to mount root from zfs:zroot []...
Mounting from zfs:zroot failed with error 2
А если у нас удалённый дедик, доступный только по ssh, то всё гораздо хуже...
И пофиг, что загрузчик видит пул и может достать из него свои конфиги, ядро и модули. И пофиг, что раздела всего два и они помечены известным UUIDом в GPT-таблицах обоих дисков. И пофиг, что все метаданные есть внутри этих разделов на диске, ведь "zfs import -f zroot" нормально монтирует пул при загрузке с аварийно-восстановительного CD! Ядро не может найти корневую ФС и всё тут!
Почему-то предыдущая в истории FreeBSD конструкция для подобной задачи (gmirror + ufs + softupdates) справляется с этой ситуацией на ура: загрузчик отрабатывает так же, далее в ядре, поскольку все метаданные хранятся в последнем секторе разделов (и не мешают ufs'у, который по своему размеру в суперблоке на 1 сектор меньше размера раздела в GPT), geom собирает зеркало автоматически, далее корневая ФС монтируется из ufs:/dev/mirror/MirrorName безо всяких бинарных кэшей, реестров и прочего подобного говна. Softupdates вместо журналирования нужны потому, что для корневой загрузочной ФС некому проиграть журнал до начала загрузки ядра. Эта конструкция проигрывает ZFS в том, что у неё происходят утечки дисковой памяти при внеплановых перезагрузках (лечится фоновым fsck в автозагрузке); также нету bit rot prevention и снэпшотов; ну и скорость проигрывает. Однако если вынести основной набор данных на ZFS, а только корневую/загрузочную ФС оставить на UFS, то выходит вполне нормально.
Кто-то скажет, что для ценителей ZFS есть Solaris, однако судя по докам оракла, на соляре та же петрушка: http://docs.oracle.com/cd/E19082-01/817-2271/gbbwc/index.html
Выводы: FreeBSD остро нуждается в патче, который позволит ядру загружаться с ZFS-пула вообще без файла zpool.cache, только по имени пула. Я точно знаю, что это возможно, ведь именно так монтируются ZFS-пулы при выполнении zpool import -f в контексте аварийно-спасательного CD. А пока для корневой ФС юзаем gmirror + ufs + softupdates.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-11-04 09:47 pm (UTC)no subject
Date: 2012-11-04 10:11 pm (UTC)* удобных снэпшотов
* файловой системы, всегда консистентной на диске, которой не нужна fsck
* обеспечения целостности данных за счёт принципа Copy-on-Write, без двойной записи всех изменений на диск (в ext3-4 и NTFS сначала пишется журнал, затем обновляется основная копия)
* автоматического предотвращения цифровой коррозии (bit rot prevention)
* встроенной поддержки RAID и менеджера томов (причём write barriers в нём работают так как надо, в отличие от линуксового lvm)
* возможности легко включить двукратное дублирование данных (вместе с RAIDом выходит 4x), включить сжатие
Встроенная поддержка RAID избавляет от необходимости покупать аппаратный RAID-контроллер с battery-backed cache (ZFS не напугать рассогласованием зеркального тома на секторном уровне).
no subject
Date: 2013-01-12 03:08 am (UTC)Да, hetzner - это жесть )
http://freebsd.down-to-details.com/uncategorized/zfs-on-root-multiple-pools-loader-cannot-find-root-file-systrem/
zpool import -R /tmp/mnt -f -o cachefile=/var/tmp/zpool.cache [pool]
- still need to mount the /
zfs set mountpoint=/ [pool]
- copy the cachefile
cp /var/tmp/zpool.cache /tmp/mnt/boot/zfs/
- umount
zfs umount -fa [pool]
- restore legacy mountpoint for /
zfs set mountpoint=/ [pool]
no subject
Date: 2014-01-29 10:43 am (UTC)посоветуете чего?