Установка CentOS на ZFS в UEFI

[@blind_oracle]

Один вопрос только — зачем? Зачем ставить CentOS на ZFS?
Разве его не проще поставить на обычную ext4/xfs, а ZFS развернуть рядом?

Если просто потому что можно — тогда вопросов нет :)

[@kvaps]

Вот несколько аргументов:

• Снапшоты корневой системы — захотел снапшот, выполнил zfs snap rpool/ROOT/centos-1@snapname в дальнейшем можно всегда к нему вернуться, если что-то пошло не так
• Динамический размер — в случае обычных фс, может случится необходимость увеличивать размер корневого или любого другого раздела, а то и вовсе в каком-то из них загончится свободное место. В zfs размер вычисляется динамически и в каждом вашем разделе, свободного места у вас будет всегда столько же, сколько и есть свободного места всего.
• Единая экосистема — вы всегда работаете с томами одинаково удобно, вы всегда можете создать, скопировать, откатить файловую систему в пару команд.

Это из того что понравилось мне, еще можно выделить такие возможности как подключение отдельного ssd-диска в качестве кэша и т.д.

А вообще вы правы, занялся я этим просто потому что было интересно и просто хотелось переделать свой «уютный маленький сервачек» по человечески. В итоге получилась такая конструкция, что я уверен, если я буду все переделывать еще раз, я сделаю точно так же :)

[@blind_oracle]

По поводу снапшотов соглашусь, в принципе.

В Nexenta, которая являет собой Solaris-ядро + Debian userspace, даже есть утилита apt-clone, которая при обновлении создаёт снапшот корневой ФС на случай чего-то непредвиденного.

[@kvaps]

На своих десктопных компьютерах я сейчас ставлю в основном btrfs, устанавливается из коробки и тоже поддерживает снапштоы, но работать с ней не столь приятно как с zfs. К тому же, в отличии от zfs, она работает только на уровне файловой системы а как следствие жестко привязанна к тому и его размеру. btrfs до zfs к сожалению пока что еще далеко :(
Тем не менее тоже довольно не плохая файловая система…

[@grossws]

Интересен вопрос стабильности btrfs в боевых применениях. У меня пока используется под docker на одном хосте и проблем не было, но этого маловато для оценки)

[@Ipeacocks]

>> в случае обычных фс, может случится необходимость увеличивать размер корневого или любого другого раздела

Ну так сетапать на LVM тогда.

[@merlin-vrn]

Аргумент против: всё это можно сделать в линуксе БЕЗ zfs: lvm — снэпшоты и динамические тома (размер и всё такое), md — raid, luks — шифрование, bcache — кэш ssd. Зато это всё делается слоями, как это принято в unix — каждый слой делает только свою задачу, зато делает её хорошо, а не один универсальный инструмент широкого профиля с миллионом настроек. Так легче за то же время охватить сознанием, «освоить», и как следствие — настроить более надёжно, чем в случае с zfs.

[@kvaps]

И в принципе я с вами согласен, к тому же lvm умеет кластеризацию в отличии от zfs, но на lvm вам все равно придется создавать отдельную файловую систему, которую при изменении размера тома все равно придется ресайзить…

[@evg_krsk]

Извиняюсь за глупый вопрос, но правильно ли я понял, что теперь при обновлении grub2-efi потребуется вручную бинарно копировать ESP на два остальных диска? И чем тогда это лучше копирования ядер?

Вы проверяли, что система загружается без каждого из трёх и без двух любых дисков?

[@kvaps]

Не совсем, на ESP разделе у вас находится только сам grub (бинарник), а на разделе boot, его конфиг, модули, ядро и initramfs.
При обновлении системы конфиг grub'а обновляется и система грузится с новым ядром.
Копировать раздел ESP на два других нужно только в случае переустановки загрузчика, т.е. выполнения команды grub2-install

Загрузку без диска пока не проверял, без двух работать точно не будет, так как RAID5 позволяет выйти из строя только один диск :)

[@evg_krsk]

mdadm --level=1 это же вроде RAID1 (как и написано в посте), нет? И он то должен выдержать вылет двух дисков из трёх :-)

[@kvaps]

А, вы про mdadm, проверял, только не на этой системе, все грузится и даже работает, mdadm алерты шлет о деградации.
Только в данном случае, без двух дисков загрузка у вас не уйдет дальше initramfs, т.к. все остальное находится уже на RAIDZ (RAID5).

[@evg_krsk]

Понятно, спасибо.

[@evg_krsk]

Ну и вы уверены, что в этом бинарнике не будет никаких изменений (требующих копирования ESP)? Я почему-то нет.

[@evg_krsk]

Но, видимо, нарваться на проблемы в этом районе довольно маловероятно :-)

[@kvaps]

Уверен, в любом другом обычном случае вы grub устанавливаете только 1 раз, при установке самой системы, после этого он у вас не переустановится пока вы не выполните команду grub-install

[@blind_oracle]

Бывает, хоть и редко, что GRUB обновляется. И тогда, если версия в MBR (или EFI) не будет соответствовать тому, что в /boot — можно нарваться на невозможность загрузиться вообще.

[@evg_krsk]

Ну вот на моём дистрибутиве, например, grub-install запускается при каждом обновлении груба (из пост-инстал скриптов). Правда, не в EFI.

Кстати, если будете что-то доставлять в ESP (утилиты диагностики вендора, ещё что...), по хорошему опять не забыть бы скопировать на два диска.

[@kvaps]

Хм, да, похоже что вы правы.
В таком случае, есть идея переопределить grub2-install. Как нибудь так например:

в /usr/local/bin/ создать исполняемый файл grub2-install такого содержания:

#!/bin/bash
/usr/sbin/grub2-install ${@}
dd if=/dev/sda1 of=/dev/sdb1 bs=4M
dd if=/dev/sda1 of=/dev/sdc1 bs=4M

Правда не знаю что из этого выйдет, надо будет попробовать сначала на виртуалке :)

[@evg_krsk]

Дистрибутивно бы как-нибудь такое решать. Даже, пожалуй, кросс-дистрибутивно.

P.S.: наверное, вместо sda1 лучше /dev/disk/by-id/ata-...part1 какой.

[@kvaps]

Разумеется лучше по uuid, я так для примера написал, вообще не факт что это сработает:)
На самом деле крайне жаль, что efi не поддерживает софт-рэйд это решило бы эту проблему. Кстати может быть есть уже где-нибудь такое решение, которое могло бы объединить несколько разделов в софт рэйд, не перезаписывая при этом суперблок — это тоже бы было весьма элегантным решением.

[@kelevra]

а /boot не получится сделать на ext4? fat16 может очень грустно навернуться в самый неподходящий момент.

[@blind_oracle]

Так у него /boot и так ext4.
А /efi нельзя, т.к. EFI поддерживает только FAT.

[@ink08]

Держал на соседнем разделе zfs, в один прекрасный момент, пришло обновление на ядро и zfs. После перезагрузки zfs.ko сломался и перестал загружаться.

[@Nastradamus]

не знаю как в линуксе, но во фре это лечится zpool upgrade, а затем, zfs upgrade. То есть, версии zpool и zfs могли поменяться.

[@ink08]

А сработали бы эти команды без загруженного модуля ядра zfs.ko?

[@Nastradamus]

Нет. Модуль ядра грузился без проблем.

[@tgz]

Достаточно ли zfs стабилен?

[@r00tGER]

В солярке отлично работает.
На линуксах есть проблемки, как говорили выше, часто вылезают после обновлений.

[@Nastradamus]

Во фре уже несколько лет в продакшне в больших компаниях используют.

[@sudoroot]

с 2008 года в продакшне под FreeBSD, ни одной проблемы, и это меня даже немного напрягает )

[@tgz]

Меня интересует исключительно ZoL. Что там во фрях/солярисах дело десятое.

[@BasilioCat]

На FreeBSD большое количество снапшотов приводит к тому, что ядро втыкает, спасает только перезагрузка. Впрочем и 10 снапшотов на сильно загруженной SSD привели к тому же.
Фичи там весьма хороши (особенно репликация), но для максимальной производительности лучше использовать файловые системы попроще.

[@sudoroot]

Можете по подробнее рассказать о проблемах, версии, кол-во снапшотов, coredump?

[@BasilioCat]

Проблема в общем скорее всего звучит так — дедлоки при высокоприоритеной записи. Разместите своп на zvol, и активно им пользуйтесь — получите панику. Версии — 10.0, 10.1, 10.2. Снапшоты — ~80 на zraid2 из 14 sas10k и 10 на страйп из 4х ssd. Кернел был без дебага (продакшен все таки), потому дамп его изучать не было особого смысла.
P.S.: Судя по интернетам, похожие проблемы есть и в zfs on linux