UFS2 или ZFS - вот в чём вопрос.

Ааа, ок.

Я джва года ждал пока механизм, идея которого с-3.14-зжена из солярки, таки стабилизируют и его можно будет юзать.

Изначально даже штатных средств для ZFS BE не было, предлагалось ставить beadm из портов (с ненулевой вероятностью отстрелить себе яйца при апгрейде на следующий релиз).

Вообще, ставить модули ядра и системные утилиты, подменяющие базовые, это гарантированный отстрел яиц при апгрейде. Тестеры OpenZFS на 12.2R об этом в очередной раз напомнили.

Во блин. UFS2 - 2002, ZFS - 2004.
Обе древние 😀

Не древние, а обкатанные!

ZFS_SERIAL_MOUNT=«YES»

Спасибо, помогло.

Перенести работающую систему на тот же диск, временно разместив систему в RAM на время переразметки диска

Это как?

mirror на md(4). ^_~

Прст я на who-you вертел ждать resilver, а в раме он мгновенный.

mirror на md(4).

Для этого нужно иметь либо большой объём ОЗУ, либо маленький объём системного пула. Если у тебя долгий resilver, то значит первое.

А так, даже при работающей системе после обновления ядра (без перезагрузки) вдруг перестало коннектиться по ssh.

Это как? Система упала в панику?

А после перезагрузки уже само ядро не нашлось.

Если загрузится с флешки и выполнить zpoo import ... , что сказало? Пул битый? Нужно понимать какова причина.

З.Ы: у меня есть сервер на ZFS который я инсталился в момент появления 10-STABLE. Он прошел все апдейты аж до текущего 13-STABLE и по сей день благополучно трудится. По сему нужно понимать что у тебя поломалось после апдейтов.

Для этого нужно иметь либо большой объём ОЗУ, либо маленький объём системного пула.

Это уже детали, не влияющие на возможность вынести пул с дисков в RAM. Насколько я знаю, только с ZFS такое можно провернуть.

долгий resilver

Меньше двух минут, но по моим меркам это долго (ибо потом ещё раскатывать обратно на диск).

Ну и в случае электрического 3.14-здеца весь пул улетит в /dev/null, так что чем быстрее он вернётся на постоянный диск, тем спокойнее. ☺

Хотя и 13-я уже не всё в порядке на стадии завершения работы

Чтоб файловая система корректно была размонтировала при выключении/ребуте, должны быть завершены все процессы которые юзают файлы к примонтированной фс. И если все сервисы корректно стопаются перед размонтированием - все будет корректно размонтированно.

К примеру, если на десктопе находясь в Х-ах написать в консои reboot - получишь кучу ругани в консоли от сервисов. Если же в DE нажать «Завершение работы» - все корректно стопается и ничего не бьется.

Если же у тебя точка монтирования «хлопается» при выключении - ищи какой сервис не останавливается.

Сейчас почему-то это поведение изменилось, и пул монтируется в подкаталог указанного каталога: /mnt/poolname.

Такое поведение дефолтное при той разметке кооторая появилась еще в ранних 11-STABLE. Если нужно видеть файловую систему как и раньше, то после импорта zfs umount -a, примонтировать zroot/ROOT/default в /mnt и потом zfs mount -a.

Из-за этого неочевидного поведения загрузчик не находит ядро по пути, указанному в /boot/loader.conf как «zfsboot:poolname» и просит указать правильный путь.

Не совсем так. Загрузчик достает название датасета из property bootfs пула с коорого нужно нагрузится, и там ищет ядро в каталоге /boot.

vfs.root.mountfrom="zfs:poolname" в /boot/loader.conf.

Загрузчик достает название датасета из property bootfs пула с коорого нужно нагрузится, и там ищет ядро в каталоге /boot.

Почему же тогда property bootfs изменилось при обычном обновлении ядра по ssh, которое до этого проводилось неоднократно и без казусов?

Чтоб файловая система корректно была размонтировала при выключении/ребуте, должны быть завершены все процессы которые юзают файлы к примонтированной фс.

Это-то понятно давно.

Почему же тогда property bootfs изменилось при обычном обновлении ядра по ssh

Ты какую-то мистику рассказываешь. Единственный раз когда у меня менялся bootfs property - это когда я клонировал сервак в онлайне на другую железку. И то, после указания bootfs все загрузилось. Очень слабо верится что у тебя оно слетело после обновления ядра. Наверно что-то другое поломало.

ОС тебе нормальную надо, а там и выбор ФС будет нормальный.

GNU/Linux с Btrfs или DragonflyBSD с HammerFS? Загадки загадываешь. ;)

Это уже детали, не влияющие на возможность вынести пул с дисков в RAM.

А с GEOM Mirror такое же возможно? Причин, почему нельзя, вроде бы не наблюдается.

Всё это звучит довольно бесполезно. Проще переустановить всё и не морочить себе мозги.

Linux с bcachefs если хочется веселья или Linux с btrfs, если хочется поскучней.

когда все файловые системы должны нормально отмонтироваться от своих точек монтирования, а не просто так хлопнуться. Особенно это касается файловых систем в точках монтирования каталога /var.

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

Хотя и 13-я уже не всё в порядке на стадии завершения работы

Что не так с 13?

Спасибо, не нужно.

Что не так с 13?

Там та же самая OpenZFS, что и на 12-й.

А с GEOM Mirror такое же возможно? Причин, почему нельзя, вроде бы не наблюдается.

Если GEOM сожрёт md, то да.

С ZFS это можно даже без md, на файлах в tmpfs (или даже на файлах в другой ФС). А вот на файлах GEOM скорее всего не взлетит.

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

У ZFS может быть один раздел с сотнями файловых систем. Пока что речь ведём в этом контексте.

переустановить

А если это боевой сервер? ☺

Но ты же хомячок, ты даже сервер видел только на картинках.

HAMMER2 выглядит вкусно. Ждём портирования на FreeBSD. ☺

Датасеты ZFS могут быть смонтированы друг в друга. Причём иерархия датасетов может отличаться от иерархии монтирования. То есть mypool/one/two/three может быть /, а mypool/four может быть /usr/local/share. И вот в таких случаях без ZFS_SERIAL_MOUNT="YES" "нижняя" точка монтирования может быть отмонтирована раньше, чем все остальные, которые примонтированы "глубже".

А ещё датасет может быть raw device со своей таблицей разделов.

Начал копировать инфу с подцепленного старого HDD. В контейнере SATA перегревается, зараза. Пришлось подцеплять по USB.

Что характерно, при копировании системной утилитой cp почему-то спотыкается на файлах с «мусорными» именами, сохранёнными из интернета и всякого рода архивов. Чтобы так просто скопировать один каталог во временный каталог — это нужно проводить целую операцию по выявлению таких вот «неправильных» файлов и папок. Как же так?!

В интернете просто не знали, что будешь делать ср когда заливали эти файлы.

Зато разработчики OpenZFS знали о ZPL (ZFS POSIX Layer) и могли предвидеть ситуацию функции копирования сохранённых файлов, у которых имена вот такие.

В общем, для нового SATA SSD выбрал файловую систему UFS2 с Soft-Updates без журналирования. Естественно не забыл о поддержке TRIM (ключик «-t»).

Считаю, что ZFS с некоего момента перестала быть управляемой. Тем не менее, на ней у меня системный пул на рабочей машине и пул raid-z с медиафайлами, который придётся видимо разносить по бэкапам и возвращаться к использованию предсказуемой классической ФС. (Может даже к NTFS).