Comments 26
Мне стали нравится статьи, в которых нихрена не понятно)
В данном случае, вероятно, патамуш я линукс никогда (пока ещё) не юзал.
Если речь о каком-то самписном мега ускорителе/упростителе, типа как я делал гуи на питоне для семерки, чтоб ваще забыть о консоли и не вводить там ничего - то круть) Удачи, чо.
Завтра попробую перечитать и погуглить.
Зы.
Похоже, все айтишники начинают с поделок для себя.
Потом приходит время, когда начинаешь делится направо и налево)
Поясняю: народ хочет устанавливать системный раздел ОС на файловую систему, которую ни ядро ни загрузчик читать не умеют. Поэтому начинается цырк с подкидыванием ядру дров и запаковки их в формат, который загрузчик сможет взять с диска и дать ядру и т.д. Короче, пердолинг ради искусства.
Нет, немного не так.
ZFSBootMenu расшифровывает пул, если включено шифрование, отображает список boot environments (если оно единственное, можно и напрямую его грузить, без меню), там по именам файлов ищёт в root датасете по пути /boot два файла: ядро и initramfs. В этом initramfs по сути находится миниатюрная файловая система, с каталогами, рутом, утилитами базовыми. И там же, в initramfs лежат различные хуки, скрипты, и драйвер zfs. ZFSBootMenu ничего не знает ни про какой драйвер zfs и не даёт его ядру, всё что делает загрузчик - распаковывает initramfs и загружает по адресу в памяти, загружает в память ядро, и отдаёт управление ядру, при этом передавая ему параметры командной строки и указатель на область памяти, где лежит initramfs. Соответсвенно, ядро загружается, монтирует initramfs, срабатывает хук и подгружается модуль ZFS. Далее этот модуль смотрит в параметры командной строки ядра, находит, какой датасет нужно смонтировать как root, замещает initramfs уже реальным рутом, с помощью switch_root / pivot_root, и уже оттуда загружается systemd, который, в свою очередь, монтирует оставшиеся датасеты по соответствующим путям
Отличная статья, спасибо. Сам гружусь с ZFSBootMenu. Ещё есть хорошая подборка статей по ZFS тут. https://github.com/ankek/awesome-zfs
это целая философия управления данными
Справедливости ради стоит отметить, что аналогичная философия применима и к btrfs, в который archinstall умеет из коробки
Тут справедливо, конечно, но снэпшоты - не единственное преимущество ZFS. Можно упомянуть нативное шифрование, RAID, удобнейшие консольные инструменты, продвинутый кэш ARC. Не знаю, насколько сейчас надёжна btrfs в плане хранения информации, у меня в 2020 как-то посыпалась btrfs из-за принудительного выключения ноута, никакой CoW, который там, по идее, должен был быть, не помог. Я пробовал по гайдам различным восстанавливать файловую систему, так и не смог восстановить. После того случая ушёл на ZFS
У btrfs есть ряд функциональных ограничений. Возможно они для вас не принципиальны, но важны для других. Тут кстати хорошее сравнение ZFS с другими ФС. https://github.com/ankek/awesome-zfs/blob/main/comparison_table_2.md
IMHO для себя я сделал выбор в пользу ZFS. Это спасало меня и мои данные не один раз.
Спасибо за установщик, попробую его. Давно мечтал уменьшить количество геморроя при установке Arch на ZFS.
Однако для меня главной проблемой оставалось обновление ядра и zfs. Может это я где-то намудрил фигни... Но у меня получалось так, что ZFS пакеты зависели от ядра, а ядро от ZFS пакетов, и я не мог обновить ни то ни другое из-за этого нормальным способом. Один раз только из Live среды, я тупо сносил ядро с zfs и ставил заново. Может что-то упускаю, и так делать ненормально?
Я не сталкивался с таким, ядро обычно никак не зависит от zfs-пакетов, только zfs пакеты зависят от ядра. Но на всякий случай подскажу: если нужно удалить пакеты, которые циклически друг от друга зависят, можно в команду pacman -Rns указать весь список пакетов, а не по одному удалять, так они все удалятся разом. Второй лайфхак (но так лучше не делать, не рекомендую) - добавить флаг -dd , тогда он не будет проверять, кто завит от этого пакета, и удалит его принудительно.
Сам я сижу на linux-lts ядре и zfs-dkms пакете (можно из AUR, можно из archzfs репозитория, как я делаю), не знаю никаких проблем при одновлениях, это самая стабильная комбинация.
Если есть желание - можем в личке подробно пообщаться на эту тему, у меня в профиле есть контактная информация
"Сам я сижу на linux-lts ядре и zfs-dkms пакете (можно из AUR, можно из archzfs репозитория"
Да ядро то накатывается, ему то че)) Вы совершенно правы, ядро обновляется вне зависимости от сторонних модулей. Только вы остаетесь без файловой системы))
stable lts ядро убивает весь вкус arch) Сторонние репо (AUR, archzfs) избавляют от всяких гарантий. Ну вот какой смысл опаздывать за ядром и при этом не иметь гарантий сборки?) ZFS по лицензионным соображениям не поддерживается разработчиками ядра и драйверы openzfs опаздывают за свежими релизами ядра. В текущем году запаздывание усугубилось и на моей машине мне пришлось откатить назад даже linux-lts в ожидании драйверов.(zfs-dkms не компилировалось пару месяцев в этом году даже с lts. Причем откатываться то пришлось как раз Live флешкой, я оставался без файловой системы. А live флешка что бы сделать arch-chroot в zfs тоже должна была быть zfs capable, ее еще нужно было поискать/сделать)
Вывод -- на двух стульях не усидеть. Если хотите bleeding-edge от arch ставьте / root на родной ext4 (ну пусть xfs, чтобы не как у всех) А уж эксперименты разворачивайте на остальных физических дисках, да и подмонтируйте куда хочется(пусть даже и в /home)
zfs мне понравилось, снепшоты на удаленный диск и инкрементально, виртуальные разделы, виртуальные рейды (хоть параллельно диски хоть последовательно), скорость, чистка. Не понравилось -- не работает команда df и вообще трудно понять сколько свободного диска)) Но, блин, на мой взгляд, модернистская стратегия arch не рифмуется с запаздыванием разрабов openzfs.
TL.DR: Root лучше на классике) А то ой)
В этом году? Мне кажется, маловероятно. zfs-2.2.7, релизнувшийся в декабре, уже поддерживал 6.12, нынешний LTS.
Доводы адекватные, конечно, но для меня плюсы перевешивают :)
А вместо df можно использовать zpool list / zfs list
И странно представить ситуацию, чтобы пришлось загружаться с LiveUSB для починки, там же будет видно при обновлении, что dkms модули не установились. Если уж проморгали как-то и перезагрузились – на этот случай есть снэпшоты и ZFSBootMenu. Прямо из ZFSBootMenu можно откатить и спокойно загрузиться.
"Прямо из ZFSBootMenu"
Я гружусь из uefi-boot материнки. Без grub, вообще без загрузчика. Весь диск форматирован zfs, без загрузочных секторов, просто раздел /boot. В ZFSBootMenu не заходил. Где это?)) Какие кнопицы зажать?))
Я советую сделать так: /boot сделать не отдельным разделом, а просто директорией в рутовом датасете, который монтируется в /
А boot раздел превратить в EFI раздел и закинуть туда EFI файл ZFSBootMenu, который можно скачать здесь: docs.zfsbootmenu.org
Таким образом, вся система лежит целиком на ZFS, включаю boot. Не стоит его делать отдельным разделом, пусть просто лежит директорией в рут. А чтобы в UEFI появилась опция ZFSBootMenu, нужно просто добавить в UEFI запись с помощью утилиты efibootmgr.
ZFSBootMenu – это один EFI файлик, он будет грузиться напрямую из UEFI, сканировать ZFS пулы, импортировать, искать там ядро / initramfs и загружать. Подробнее советую прочитать в документации ZFSBootMenu, там очень хорошо написано :)
Именно zfs-2.2.7 и 6.12 модулей dkms и пришлось подождать. Вы совершенно правы. Еще была ветка на AUR 2.2.5 с постфиксом dev Или что то вроде того)) Типа волонтеры development branche openzfs))
Да, бывает и такое) Но бывает и как сейчас: последняя версия ZFS поддерживает ядро 6.16.
В целом, обычно разработчики ZFS не гонятся со всех ног выпускать новый релиз сразу после релиза нового ядра. Новый релиз выходит тогда, когда становится готов набор пул реквестов, которые они хотят видеть в этом релизе, там свой график.
А вообще, да, есть энтузиасты, которые к последней стабильной версии ZFS добавляют cherry-pick патчи для поддержки наипоследнейшего и новейшего ядра, когда ZFS отстаёт. Тоже видел такие пакеты в AUR
Дополню на всякий случай про Live флешку с ZFS. ISO можно взять тут: https://github.com/stevleibelt/arch-linux-live-cd-iso-with-zfs/releases
Либо в релизах моего репозитория, там тоже автоматическая сборка ISO с ZFS: https://github.com/okhsunrog/archinstall_zfs/releases
Ещё можно собрать такой ISO самому, в README моего проекта есть инструкции.
Ага) И причем лучше сделать эту флешку прямо сейчас) А то потом, перед черным экраном, будет скушновато) Или искать у приятелей -- у кого есть рабочая *nix система с командой dd (а такая система есть не у многих приятелей) чтобы live image таки сделать))) А в идеологии arch такая флешка может и понадобиться))
Ещё раз: если у вас есть ZFSBootMenu, никакой LiveUSB не понадобится. ZFSBootMenu это сам по себе маленький Линукс.
Оттуда можно как откатить систему к прошлому снэпшоту, так и сделать chroot, поменять что нужно в системе. Есть ещё более жирный образ ZFSBootMenu Recovery, я предпочитаю им пользоваться вместо стандартного. Там богатый набор утилит, которые могут понадобиться при восстановлении системы.
Но я так и не пользовался этим. Просто через zrepl настроил снэпшоты раз в час. Если что-то пошло вдруг не так – я всегда из ZFSBootMenu могу парой нажатий кнопок откатить корневой датасет к тому состоянию, в котором он был час, или два часа назад, к примеру.
Очень интересно, спасибо! Раз уж преисполнились zfs, не тестировали случайно работу direct io с nvme? В предыдущих версия несмотря на primarycache=metadata и secondarycache=metadata все всеравно проходило через code path для ARC. Сейчас нет доступа к свободному железу с nvme, в общем 2.3 не успел протестировать. При многопоточной нагрузке раньше все было печально с загрузкой CPU и iowait, никакие настройки async очередей для чтения записи не помогали (точнее помогали плохо). Обсуждение: https://github.com/openzfs/zfs/pull/10018
Интересный кейс. Можно увидеть вашу конфигурацию? И ещё типовой сценарий работы с данными? ARC это виртуальный кэш в оперативке. Быстрее RAM ничего в вашем компьютере/сервере нет. Помогает с горячими данными на чтении. Secondary cache это самый быстрый из блочных устройств. Обычно nvme ssd. Туда вытесняют теплые данные, чтобы в тащить в ARC если нужно. Но это все помогает при интенсивном чтении. При интенсивной записи кэш на чтение прироста не даёт. Тут важнее конфигурация zpool. Raidz и dRAID это аналоги Raid5. Медленная запись, быстрое чтение. Для интенсивной записи лучше выбрать stripe или mirror. Сравнение различных конфигураций есть тут
https://github.com/ankek/awesome-zfs/blob/main/zfs-raid-comparison.md
Уже там не работаю). Это был просто один nvme, без всяких raid{x}. Типовой сценарий виртуалки (zvol's), volblocksize 16k, при генерации нагрузки с fio были совершшенно неадекватные показатели l.avg, iowait, в реальном кейсе при одновременной миграции нескольких вм (4) на сетке даже в 10гбит io на уже работающих на пуле вм вставал колом. В общем-то это и подтвердилось в чистых тестах fio. btrfs на этом же железе c fio тестами показывал <10% io.wait, zfs - больше 60%. сжатие выключено, все ashift учтены ).
Наркомания про directio: https://github.com/openzfs/zfs/issues/8381#issuecomment-529174195 , в конце треда параметры которые помогли на zfs 2.x somewhat (iowait 40%), но всеравно не как btrfs на том же чистом тесте с fio. (iowait <10%)
Вообще очень странный кейс. В треде больше про тюнинг. Оффициальная документация здесь https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#id78
У меня по прежнему ощущение что пул и датасет могли быть сконфигурированы с дефолтными параметрами. Из моего опыта, ZFS делает btrfs в том числе по производительности iops на одинаковом железе.
Я бы протестировал, но у меня на единственной системе с NVMe включено шифрование диска и сжатие, мне кажется, именно они будут узким местом, а не ARC. Хотя может я и ошибаюсь, попробовать потестировать на отдельном датасете
Arch Linux на ZFS для людей: новый TUI-установщик archinstall_zfs