Не все йогурты одинаково полезны

ZFS в качестве корневой загрузочной файловой системы 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.