Георгий человек хороший, он сразу дал тебе план что делать

Это я просто ребутнул и подождал. По результату видим это

OOM. Вообще интересно. Сколько оперативной памяти?

12гб

OOM. Вообще интересно. Сколько оперативной памяти?

fsck может ОЧЕНЬ долго работать

Может ему свапа не хватает. Сейчас я в рекавери сеть поднял и ssh. Сейчас подрублюсь с удобного места

Так он в панику по итогу уходит.

На втором скриншоте я вижу, что кто-то не выдержал и стал жать Ctrl-C. fsck на большом диске может бегать и час и два

Там прошли сутки.

Прошли сутки, fsck работал, диском шуршал? Какой объем xfs?

Это не проксмокс?

Все файлы на месте. До конца скраба 50м. Так что вот такие траблы с zfs по сути на пустом месте бывают. Пилить и пилить ещё. Ещё снапшоты почистил. на самом первом скриншоте - kernel panic. это действительно - очень сильно похоже на проблемы с hardware - или память, или какое-то другое hardware (Intel процесор, материнская плата и т.п.) Есть ли возможность проверить память сервера с помощью https://memtest.org/ ? Хотя бы несколько полных проходов, но для большей уверенности - оставить memtest работающим на сутки. если там глючная память - то скорее всего, что именно она и является причиной такого странного поведения сервера. Судя по скриншоту - материнская плата там P7Q57-M DO - она только non-ECC память поддерживает. кроме того, версия 2.1.11 все-таки очень старая и содержит data corruption bug, уже есть 2.1.15 с исправлением этой и многих других ошибок. 2.1.16 на дебиан/убунту ядрах, как я понимаю, собираться и работать не будет, но 2.1.15 должна работать. https://github.com/openzfs/zfs/releases/tag/zfs-2.1.14 Note: This release contains an important fix for a data corruption bug. Full details are in the issue (#15526) and bug fix (#15571). There's also a developer's bug summary that gives a good overview. We recommend everyone either upgrade to 2.2.2 or 2.1.14 to get the fix. The bug can cause data corruption due to an incorrect dirty dnode check. This bug is very hard to hit, and really only came to light due to changes in cp in coreutils 9.x. It's extremely unlikely that the bug was ever hit on EL7 or EL8 when running cp since they all use coreutils 8.x which performs file copies differently.

кроме того, как на этом сервере с 12 GiB non-ECC RAM настроен swap? если через zvol - то именно это и может приводить к deadlock и kernel panic. Using a zvol for a swap device on Linux Swap deadlock in 0.7.9 #7734

Я по ошибке смотрел и уменьшил Арк. Может это помогло? любой разумный размер ZFS Adaptive Replacement Cache (ZFS ARC) не должен приводить к page fault и kernel panic: System is deadlocked on memory. какой размер ZFS ARC был выставлен изначально на этом сервере с 12 GiB RAM, и какой размер ZFS ARC стал после уменьшения, когда все начало работать нормально и без каких-либо проблем? что говорит https://memtest.org/ - есть ли ошибки памяти на этом сервере с non-ECC RAM ?

Dedup включен, памяти под таблицу дедупликации надо много, просчитано? Судя по коэффициенту эффект не большой, есть смысл выключить, полагаю.

Там железо старое. Если ещё раз повторится, я тупо поменяю на атлон х4 ам4.

Dedup включен, памяти под таблицу дедупликации надо много, просчитано? Судя по коэффициенту эффект не большой, есть смысл выключить, полагаю.

12gb под файлопомойку обычную никаких нагрузок

https://opennet.ru/62552/

опять кстати про проперти и мелочи не написали, тут явно подсвечу из того что смог дотащить лично: - теперь xattr=on - синоним к xattr=sa, так что ничего не меняя и на старых пулах xattrs (считай мета о файле дополнительная) будет работать быстрее - при компрессии теперь учитывается итоговый минимальный размер аллокации на диске, т.е. теперь раньше будет выход из сжатия если оно бессмыссленно = экономия cpu

вот тут подумал -- а что мешает поддержать автомаунт датасета по тому что передано ядру в root= ? просто никто не парился или какие-то принципиальные моменты?

эти параметры скрипты разбирают, пока не совсем понял что имеется в виду но технически там всё что хочешь можно сделать

Ну например я могу указать рутфсом любой subvolume на любом диске в случае btrfs. Чисто как опция *ядру*, после чего ядро само подмаунтит себе что надо куда надо и забутится оттуда. Без никаких скриптов.

так оно умеет так прямо сейчас

То есть эту вот строчку root=ZFS=rpool/чтото распарсит именно ядро? Ну в случае если зфс в него вкомпилировано

нет, скрипты, т.е. в initramfs лежит всё нужное чтобы после запуска ядра дальше rootfs откуда сказал примонтировать

Ну вот я и говорб, что здорово было бы это без монструаозных инитрамфсов делать

чтобы что?) указание rootfs в любом случае же не вшивается в ядро, независимо от ФС. Мб есть хитрые варианты, но это уже для любителей

Ну вообще-то rootcmdline можно и вшить в ядро, есть такая опция при компиляции

можно то всё, спору нет, вопрос надобности и универсальности zfsbootmenu ещё можете глянуть если интересно, как раз пример камаза вместо чемодана)

Ну и в целом -- если есть необходимость в целом инитрамфс причём безальтернативно -- то универсальность как раз пострадала

Initramfs необходим всегда. В случае zfs он содержит модули вместо ядра, так что на суммарный размер это вообще никак не влияет. Если вы хотите, чтобы был один загрузочный файл — вам надо смотреть в сторону UKI Если вам надо минимизировать footprint — Arch

Если вы говорите не про роутер и прочий эмбед — необходим. Куда вы денете сами инитскрипты, скрипты lvm, LUKS и md, earlyboot и все прочее? А разбирать околоембеды в чате про zfs — несколько странно