Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Один вопрос только — зачем? Зачем ставить CentOS на ZFS?
Разве его не проще поставить на обычную ext4/xfs, а ZFS развернуть рядом?
Если просто потому что можно — тогда вопросов нет :)
Разве его не проще поставить на обычную ext4/xfs, а ZFS развернуть рядом?
Если просто потому что можно — тогда вопросов нет :)
Вот несколько аргументов:
Это из того что понравилось мне, еще можно выделить такие возможности как подключение отдельного ssd-диска в качестве кэша и т.д.
А вообще вы правы, занялся я этим просто потому что было интересно и просто хотелось переделать свой «уютный маленький сервачек» по человечески. В итоге получилась такая конструкция, что я уверен, если я буду все переделывать еще раз, я сделаю точно так же :)
- Снапшоты корневой системы — захотел снапшот, выполнил zfs snap rpool/ROOT/centos-1@snapname в дальнейшем можно всегда к нему вернуться, если что-то пошло не так
- Динамический размер — в случае обычных фс, может случится необходимость увеличивать размер корневого или любого другого раздела, а то и вовсе в каком-то из них загончится свободное место. В zfs размер вычисляется динамически и в каждом вашем разделе, свободного места у вас будет всегда столько же, сколько и есть свободного места всего.
- Единая экосистема — вы всегда работаете с томами одинаково удобно, вы всегда можете создать, скопировать, откатить файловую систему в пару команд.
Это из того что понравилось мне, еще можно выделить такие возможности как подключение отдельного ssd-диска в качестве кэша и т.д.
А вообще вы правы, занялся я этим просто потому что было интересно и просто хотелось переделать свой «уютный маленький сервачек» по человечески. В итоге получилась такая конструкция, что я уверен, если я буду все переделывать еще раз, я сделаю точно так же :)
По поводу снапшотов соглашусь, в принципе.
В Nexenta, которая являет собой Solaris-ядро + Debian userspace, даже есть утилита apt-clone, которая при обновлении создаёт снапшот корневой ФС на случай чего-то непредвиденного.
В Nexenta, которая являет собой Solaris-ядро + Debian userspace, даже есть утилита apt-clone, которая при обновлении создаёт снапшот корневой ФС на случай чего-то непредвиденного.
На своих десктопных компьютерах я сейчас ставлю в основном btrfs, устанавливается из коробки и тоже поддерживает снапштоы, но работать с ней не столь приятно как с zfs. К тому же, в отличии от zfs, она работает только на уровне файловой системы а как следствие жестко привязанна к тому и его размеру. btrfs до zfs к сожалению пока что еще далеко :(
Тем не менее тоже довольно не плохая файловая система…
Тем не менее тоже довольно не плохая файловая система…
>> в случае обычных фс, может случится необходимость увеличивать размер корневого или любого другого раздела
Ну так сетапать на LVM тогда.
Ну так сетапать на LVM тогда.
Аргумент против: всё это можно сделать в линуксе БЕЗ zfs: lvm — снэпшоты и динамические тома (размер и всё такое), md — raid, luks — шифрование, bcache — кэш ssd. Зато это всё делается слоями, как это принято в unix — каждый слой делает только свою задачу, зато делает её хорошо, а не один универсальный инструмент широкого профиля с миллионом настроек. Так легче за то же время охватить сознанием, «освоить», и как следствие — настроить более надёжно, чем в случае с zfs.
Извиняюсь за глупый вопрос, но правильно ли я понял, что теперь при обновлении grub2-efi потребуется вручную бинарно копировать ESP на два остальных диска? И чем тогда это лучше копирования ядер?
Вы проверяли, что система загружается без каждого из трёх и без двух любых дисков?
Вы проверяли, что система загружается без каждого из трёх и без двух любых дисков?
Не совсем, на ESP разделе у вас находится только сам grub (бинарник), а на разделе boot, его конфиг, модули, ядро и initramfs.
При обновлении системы конфиг grub'а обновляется и система грузится с новым ядром.
Копировать раздел ESP на два других нужно только в случае переустановки загрузчика, т.е. выполнения команды grub2-install
Загрузку без диска пока не проверял, без двух работать точно не будет, так как RAID5 позволяет выйти из строя только один диск :)
При обновлении системы конфиг grub'а обновляется и система грузится с новым ядром.
Копировать раздел ESP на два других нужно только в случае переустановки загрузчика, т.е. выполнения команды grub2-install
Загрузку без диска пока не проверял, без двух работать точно не будет, так как RAID5 позволяет выйти из строя только один диск :)
mdadm --level=1 это же вроде RAID1 (как и написано в посте), нет? И он то должен выдержать вылет двух дисков из трёх :-)
Ну и вы уверены, что в этом бинарнике не будет никаких изменений (требующих копирования ESP)? Я почему-то нет.
Но, видимо, нарваться на проблемы в этом районе довольно маловероятно :-)
Уверен, в любом другом обычном случае вы grub устанавливаете только 1 раз, при установке самой системы, после этого он у вас не переустановится пока вы не выполните команду grub-install
Бывает, хоть и редко, что GRUB обновляется. И тогда, если версия в MBR (или EFI) не будет соответствовать тому, что в /boot — можно нарваться на невозможность загрузиться вообще.
Ну вот на моём дистрибутиве, например, grub-install запускается при каждом обновлении груба (из пост-инстал скриптов). Правда, не в EFI.
Кстати, если будете что-то доставлять в ESP (утилиты диагностики вендора, ещё что...), по хорошему опять не забыть бы скопировать на два диска.
Кстати, если будете что-то доставлять в ESP (утилиты диагностики вендора, ещё что...), по хорошему опять не забыть бы скопировать на два диска.
Хм, да, похоже что вы правы.
В таком случае, есть идея переопределить grub2-install. Как нибудь так например:
в /usr/local/bin/ создать исполняемый файл grub2-install такого содержания:
Правда не знаю что из этого выйдет, надо будет попробовать сначала на виртуалке :)
В таком случае, есть идея переопределить 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
Правда не знаю что из этого выйдет, надо будет попробовать сначала на виртуалке :)
Дистрибутивно бы как-нибудь такое решать. Даже, пожалуй, кросс-дистрибутивно.
P.S.: наверное, вместо sda1 лучше /dev/disk/by-id/ata-...part1 какой.
P.S.: наверное, вместо sda1 лучше /dev/disk/by-id/ata-...part1 какой.
Разумеется лучше по uuid, я так для примера написал, вообще не факт что это сработает:)
На самом деле крайне жаль, что efi не поддерживает софт-рэйд это решило бы эту проблему. Кстати может быть есть уже где-нибудь такое решение, которое могло бы объединить несколько разделов в софт рэйд, не перезаписывая при этом суперблок — это тоже бы было весьма элегантным решением.
На самом деле крайне жаль, что efi не поддерживает софт-рэйд это решило бы эту проблему. Кстати может быть есть уже где-нибудь такое решение, которое могло бы объединить несколько разделов в софт рэйд, не перезаписывая при этом суперблок — это тоже бы было весьма элегантным решением.
а /boot не получится сделать на ext4? fat16 может очень грустно навернуться в самый неподходящий момент.
Держал на соседнем разделе zfs, в один прекрасный момент, пришло обновление на ядро и zfs. После перезагрузки zfs.ko сломался и перестал загружаться.
Достаточно ли zfs стабилен?
В солярке отлично работает.
На линуксах есть проблемки, как говорили выше, часто вылезают после обновлений.
На линуксах есть проблемки, как говорили выше, часто вылезают после обновлений.
с 2008 года в продакшне под FreeBSD, ни одной проблемы, и это меня даже немного напрягает )
Меня интересует исключительно ZoL. Что там во фрях/солярисах дело десятое.
На FreeBSD большое количество снапшотов приводит к тому, что ядро втыкает, спасает только перезагрузка. Впрочем и 10 снапшотов на сильно загруженной SSD привели к тому же.
Фичи там весьма хороши (особенно репликация), но для максимальной производительности лучше использовать файловые системы попроще.
Фичи там весьма хороши (особенно репликация), но для максимальной производительности лучше использовать файловые системы попроще.
Можете по подробнее рассказать о проблемах, версии, кол-во снапшотов, coredump?
Проблема в общем скорее всего звучит так — дедлоки при высокоприоритеной записи. Разместите своп на zvol, и активно им пользуйтесь — получите панику. Версии — 10.0, 10.1, 10.2. Снапшоты — ~80 на zraid2 из 14 sas10k и 10 на страйп из 4х ssd. Кернел был без дебага (продакшен все таки), потому дамп его изучать не было особого смысла.
P.S.: Судя по интернетам, похожие проблемы есть и в zfs on linux
P.S.: Судя по интернетам, похожие проблемы есть и в zfs on linux
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка CentOS на ZFS в UEFI