Да диски у меня сыпались. Но zfs крашила систему своим sd_sync, txd_sync и т.д. Вот в чем печаль. В таких случаях ничего не остаётся, кроме как сохранять данные, пока оно не повесили систему и полностью заменять диски на исправные. Создавать тупо пул и вливать назад. Я целый день потерял пытаясь сделать реплейс. у меня еще ни разу не было проблем с zpool replace в серверах где стоит много HDD в режиме RAIDZ2 - все эти HDD всегда использовал в режиме "whole disk", так что замена в zpool сбойного диска на новый - всегда была тривиальной операцией, всего одной командой. А что надо сделать для того, чтобы вызвать kernel panic в процессе выполнения команды zpool replace ? В какой именно версии zfs команда zpool replace на Вашем компьютере вызывает kernel panic в sd_sync / txd_sync ? Выполнять эту команду на сервере надо уже после того, как сбойный HDD заменен на новый. когда надо получить большое по объему хранилище на много терабайт - тогда именно сервера с HDD будут самым целесообразным выбором, если эти HDD собирать в RAIDZ2 vdev, чтобы получить избыточность и защиту данных. Если у Вас там все часто сыпется и глючит постоянно - может быть там память без ECC, и Memtest86+ смог бы помочь найти выявить проблемы? Если запустить его на ночь или на несколько суток. При использовании zfs рекомендуется, чтобы память была ECC, потому что, как я понимаю, глючная память может привести к серьезным разрушениям файловой системы zfs, так что потом ее будет или очень трудно или вообще невозможно восстановить. да, файловая система zfs не является идеальной и у нее много недостатков, но для очень большого количества применений - на текущий момент она является наилучшим выбором, если нужна сохранность данных - если использовать вариант zfs из стабильного репозитория, а не из тестового репозитория zfs-testing. для целого класса задач именно zfs будет наилучшим выбором, потому что ближайшие аналоги и конкуренты - btrfs и bcachefs оказываются еще менее стабильными и еще менее надежными. Возможно в будущем ситуация изменится, но пока что я сколько не искал - не смог найти лучшего варианта файловой системы, чем zfs. Или я что-то пропустил и уже появилась какая-то новая файловая система, которая лучше, чем OpenZFS?

У вас не было. У меня было, много, на разном железе. ZFS многократно крашилась из за летящих винтов и уходила в панику. Она не способно решать сложные задачи, если винты начинают тупить, то она сама тупит, а не решает конфликты. Я легко покажу и докажу и воспроизвежу. Вы скажете железо не то - а я покажу требование к железу официальные и на этом вопрос будет исчерпан. Да и к тому же я говна так хорошо в свое время покушал и ночей не поспал, что доверять я ей до конца не буду НИКОГДА.

Про zpool replace вообще скажу, что концепт замены совершенно отсталый. Если я изначально не по id сделал, то возникает путаница. Например у меня был диск, который я поставил на замены, а потом передумал - теперь у меня висит старый id не понятно чего was "такой то" и рядом идет ресилвер нового. Абсолютно не логично. А логично было бы, чтобы zfs записывала свои собственные id в пулах и сама ими рулила. Как например в mdadm, пофиг какая там буква - он его найдет, если они местами поменяются и массив заработает.

Так в ZFS также.

Так в ZFS также.

Вот у меня на серваке был прикол только недавно. Он местами перепутал винты буквами и потерял винт, потому что у него другая буква.

А он был подключен. Просто буква съехала. И приходилось делать замену))) Очень продуманно

Вроде же рекомендуют не делать по буквам

Вот у меня на серваке был прикол только недавно. Он местами перепутал винты буквами и потерял винт, потому что у него другая буква.

Какая версия ZFS?

Вроде же рекомендуют не делать по буквам

Еще случай. Клянусь. У меня исчез ид винта и он стали видится только по wwn. Тоже реплейс по wwn

Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось.

Свои идишники ставить и сама винты расставлять по местам. Вот это было бы правильно.

Еще случай. Клянусь. У меня исчез ид винта и он стали видится только по wwn. Тоже реплейс по wwn

При этом мы вообще не говорим о выходе из строя. Это простой дебилизм

Еще случай. Клянусь. У меня исчез ид винта и он стали видится только по wwn. Тоже реплейс по wwn

Вот это вообще звучит дико. Не знаю как ZFS в таком случае должен отработать и проверить не получится у меня

Какая версия ZFS?

Все дебиановское тупо фулл апгрейдом иду и принципиально не ставлю никакие тюнячки

Вот это вообще звучит дико. Не знаю как ZFS в таком случае должен отработать и проверить не получится у меня

Свои иды ставить и сканить при импорте.

Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось.

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

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

Наоборот. Ид изменился, стал видится как цифры. Пришлось по wwn его реплейсить назад

И он понял что винта нет. Вот и все. Это тупо

И он понял что винта нет. Вот и все. Это тупо

Это после ребута?

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

Вот у меня уже есть пул и на нем данные. Мне только реплейсить получается, если он считает что винта нет

Это после ребута?

Да

Переделать - искал информацию. Но это не просто ибо сохранить 4тб не быстро, и люди ждут

А потерять данные - собачьи консервы

Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось.

Если ты скажешь искать по всем шинам - оно и будет искать по всем шинам

Поэтому вот такие приколы есть и они не должны быть. Да, железо подглючивает, да не очень удачная конфигурация. Но это не допустимо, если устройство доступно, а он тупо смотрит по путям прописанным. Он должен их выдирать вне зависимости от того как они подключены при импорту.

zpool import -d /dev/.....

А то, что ты описываешь это не бесплатная система из инета, а энтепрайз решение за ляма 3-4

Когда тебе и надёжность, и удобству, и по одной кнопке всё делается само

Когда тебе и надёжность, и удобству, и по одной кнопке всё делается само

Это скрипт за 20 минут в сервисе zfs-import. Просто такое удивляет, что не продумано.

Если ты не читаешь блядский FAQ https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html

То к чему вопросы?

Это скрипт за 20 минут в сервисе zfs-import. Просто такое удивляет, что не продумано.

Как говорится - коммиты открыты

Если ты готов поддерживать этот скрипт на ubuntu, debian, redhat, centos, fedora и т.д. и т.д. и отслеживать изменения, чтобы этот скрипт не ломался при обновлении ядра То флаг в руки :)

Про zpool replace вообще скажу, что концепт замены совершенно отсталый. Если я изначально не по id сделал, то возникает путаница. Например у меня был диск, который я поставил на замены, а потом передумал - теперь у меня висит старый id не понятно чего was "такой то" и рядом идет ресилвер нового. Абсолютно не логично. А логично было бы, чтобы zfs записывала свои собственные id в пулах и сама ими рулила. Как например в mdadm, пофиг какая там буква - он его найдет, если они местами поменяются и массив заработает.

mdadm кстати тоже тебя нахер пошлёт если у тебя не записан UUID пула в файлике конфигов. И ты если что делаешь это ручками, хотя казалось бы просто добавить его автоматически по команде create

и нейминг тоже пойдёт лесом, и вместо md126 с 5 ssd у тебя будет md126 с 4 HDD, а 5 ssd станут md127

Если не делать конфигурационный файл ручками

Если ты готов поддерживать этот скрипт на ubuntu, debian, redhat, centos, fedora и т.д. и т.д. и отслеживать изменения, чтобы этот скрипт не ломался при обновлении ядра То флаг в руки :)

Ну несколько лямов вы говорили. Сделаю за 20% скажем так. Ну а я юзаю дебиан. Для дебиана напишу попозже как время будет чисто для себя. Поддерживать там нечего, да и от дистрибутива не думаю что может быть зависимо. Просто при импорте проверяется каждым из вариантов все ли импортнуто. Все тоже, что и делал бы человек ручками. При этом периодически бы искал уже в рабочем пуле по всем символьным ссылкам и разделам винты в пуле и писал их в соответствующие файлы. В несколько этапов, зато полностью автономно. У разработчиков zfs гораздо больше вариантов. Я посмотрел faq - какая же это *ня.

Флаг в руки

Они тупо могли бы в начало диска писать свой id и при монтировании каждый диск сопостовлять и все - нет проблемы

Ну несколько лямов вы говорили. Сделаю за 20% скажем так. Ну а я юзаю дебиан. Для дебиана напишу попозже как время будет чисто для себя. Поддерживать там нечего, да и от дистрибутива не думаю что может быть зависимо. Просто при импорте проверяется каждым из вариантов все ли импортнуто. Все тоже, что и делал бы человек ручками. При этом периодически бы искал уже в рабочем пуле по всем символьным ссылкам и разделам винты в пуле и писал их в соответствующие файлы. В несколько этапов, зато полностью автономно. У разработчиков zfs гораздо больше вариантов. Я посмотрел faq - какая же это *ня.

ну раз так, то дважды флаг в руки

ну раз так, то дважды флаг в руки

Так и делаю. dev поменялся и все - приехали.

Так и делаю. dev поменялся и все - приехали.

Нет? /dev/disk/by-id/ И вперёд. Если у тебя поменялся ID диска, то ты хорош, расскажи как

Нет? /dev/disk/by-id/ И вперёд. Если у тебя поменялся ID диска, то ты хорош, расскажи как

Какое то время назад я даже скрин скидывал сюда в горячке. Поищи мои мессаджи.

Какое то время назад я даже скрин скидывал сюда в горячке. Поищи мои мессаджи.

Спасибо, мне есть чем заняться, чем искать вырожденный случай, как человек используя китайские диски за 0.1 рубля делает удивлённое лицо пикачу, когда с ними происходит сбой

Был /dev/by-id/ОЛОЛОЛО_ПРОИЗВОДИТЕЛЬ. Стал после ребута /dev/by-id/7381723874981713 или типа того. ZFS сказала пока. Проверил диск на смарт, на что угодно - все норм

Спасибо, мне есть чем заняться, чем искать вырожденный случай, как человек используя китайские диски за 0.1 рубля делает удивлённое лицо пикачу, когда с ними происходит сбой

Это кстати был toshiba red

Красиво

В документации к OpenZFS рекомендуется использовать имена дисков /dev/disk/by-id/ - например: /dev/disk/by-id/nvme-SAMSUNG_MZQL23T8HCLS-00A07_S64HNE0R803057 тут же сразу видно и тип накопителя, и название производителя диска, и его модель и его серийный номер. очень удобный способ адресовать диски, и при этом - имена всегда уникальны и никогда не изменяются. почему бы не использовать именно этот метод, как и рекомендуется в документации? тем более, что имена дисков в /dev/disk/by-id/ - это просто симлинки на все те же самые /dev/sdX и /dev/nvmeX Вы же не получаете никаких преимуществ, используя постоянно меняющиеся имена дисков /dev/sdX - тем более, что в случае выхода диска из строя невозможно будет быстро определить, какой именно диск надо менять - это неудобно. Вот у меня на серваке был прикол только недавно. Он местами перепутал винты буквами и потерял винт, потому что у него другая буква. А он был подключен. Просто буква съехала. И приходилось делать замену))) Очень продуманно там не может съехать буква, имена дисков в /dev/disk/by-id/ статичны и никогда не меняются. имена дисков /dev/sdX можно использовать только для тестирования, но не для production. Вы сами себе создаете проблемы на ровном месте, не читая документацию и не делая, как там рекомендуется. Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось. по умолчанию - включен сервис zfs-import-cache.service # systemctl status zfs-import-cache.service если для каких-то странных и не понятных целей надо, чтобы не использовался файл /etc/zfs/zpool.cache - то тогда имеет смысл выключить сервис zfs-import-cache.service и включить сервис zfs-import-scan.service # systemctl status zfs-import-scan.service но в результате будет - замедление импорта zpool, потому что zfs тогда придется сканировать все диски, а это может быть очень не быстрый процесс, если дисков в сервере много. Вас разве кто-то насильно принуждает пользоваться файловой системой OpenZFS ? Вообще не понятно, в чем проблема? Если не хотите - не пользуйтесь.

В документации к OpenZFS рекомендуется использовать имена дисков /dev/disk/by-id/ - например: /dev/disk/by-id/nvme-SAMSUNG_MZQL23T8HCLS-00A07_S64HNE0R803057 тут же сразу видно и тип накопителя, и название производителя диска, и его модель и его серийный номер. очень удобный способ адресовать диски, и при этом - имена всегда уникальны и никогда не изменяются. почему бы не использовать именно этот метод, как и рекомендуется в документации? тем более, что имена дисков в /dev/disk/by-id/ - это просто симлинки на все те же самые /dev/sdX и /dev/nvmeX Вы же не получаете никаких преимуществ, используя постоянно меняющиеся имена дисков /dev/sdX - тем более, что в случае выхода диска из строя невозможно будет быстро определить, какой именно диск надо менять - это неудобно. Вот у меня на серваке был прикол только недавно. Он местами перепутал винты буквами и потерял винт, потому что у него другая буква. А он был подключен. Просто буква съехала. И приходилось делать замену))) Очень продуманно там не может съехать буква, имена дисков в /dev/disk/by-id/ статичны и никогда не меняются. имена дисков /dev/sdX можно использовать только для тестирования, но не для production. Вы сами себе создаете проблемы на ровном месте, не читая документацию и не делая, как там рекомендуется. Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось. по умолчанию - включен сервис zfs-import-cache.service # systemctl status zfs-import-cache.service если для каких-то странных и не понятных целей надо, чтобы не использовался файл /etc/zfs/zpool.cache - то тогда имеет смысл выключить сервис zfs-import-cache.service и включить сервис zfs-import-scan.service # systemctl status zfs-import-scan.service но в результате будет - замедление импорта zpool, потому что zfs тогда придется сканировать все диски, а это может быть очень не быстрый процесс, если дисков в сервере много. Вас разве кто-то насильно принуждает пользоваться файловой системой OpenZFS ? Вообще не понятно, в чем проблема? Если не хотите - не пользуйтесь.

М, интересно, вот это про этот сервис я не знал

М, интересно, вот это про этот сервис я не знал

Всё-таки есть польза от этого гпт бота))

Всё-таки есть польза от этого гпт бота))

Да

Хамство с какой целью и по какой причине? Хамство имеет в основе психологические причины: хамы пытаются ощутить собственную важность, уничтожая достоинство жертвы. При помощи хамства люди стараются манипулировать другими или оказывать на них давление, чтобы прийти к личной выгоде. «Нередко такое поведение представляет собой механизм защиты, хамство бывает от страха или неуверенности, таким образом человек переносит акценты с имеющихся у него недостатков либо, наоборот, привлекает к себе внимание, пусть и неблагочестивым поведением. Хамы сами страдают от своих действий, вредя своему эмоциональному и психологическому благополучию», — говорят психологи. Хамство может иметь открытую форму — проявляясь в грубости и насмешках, или скрытую — являясь пассивно-агрессивным поведением. Психологическая причина хамства бывает в: • низкой самооценке — хамство является компенсацией негативных ощущений, создает иллюзорные контроль и власть; • эмоциональной реакции — при помощи хамства человек может снизить отрицательную энергию от какого-то события или действия, вызвавшего гнев или стресс; • желании властвовать и контролировать — через хамское поведение демонстрируется доминирующая позиция, сила и важность; • зависти и ревности — агрессивное поведение к жертве может проявиться, если хам ревнует или завидует, его цель — в подрыве достижений и качеств оппонента; • недостатке эмпатии — если человеку сложно понять переживания и эмоции другого человека, он может проявить бесчувственность либо хамство; • социокультурных факторах — среда, где пришлось расти человеку, соприкосновение его с теми или иными культурными и социальными нормами формируют поведенческие паттерны, то есть человек может хамить по привычке, он просто не знает, что взаимодействовать можно иначе.

Был /dev/by-id/ОЛОЛОЛО_ПРОИЗВОДИТЕЛЬ. Стал после ребута /dev/by-id/7381723874981713 или типа того. ZFS сказала пока. Проверил диск на смарт, на что угодно - все норм если в Вашем компьютере глючная память и время от времени Linux будет падать в kernel panic по причине invalid opcode - Вы же не будете на основании этого говорить, что "операционная система Linux не смогла в стабильность" ? вот точно так же и здесь - это просто глючное hardware, и на таком глючном оборудовании OpenZFS не может корректно работать, как и не сможет работать в сервере с глючной памятью, или другим каким-то глючным оборудованием. и только если все hardware работает на 100% надежно - только тогда уже можно говорить о проблемах OpenZFS.

доверять я ей до конца не буду НИКОГДА. никто и не предлагает доверять ей до конца. по крайней мере, я такого никогда не предлагал. уже было много раз, что в OpenZFS появлялись ошибки, которые приводили к data corruption, например: https://github.com/openzfs/zfs/issues/15526 https://github.com/openzfs/zfs/issues/15933 и про две самые большие ошибки, которые приводят к data corruption даже в документации было написано: https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#sending-and-receiving-streams поэтому да, Вы говорите все верно - доверять файловой системе OpenZFS нельзя. и доверять "резервным копиям" созданным с помощью репликации zfs датасетов - тоже нельзя, они в прошлом не раз уже оказывались битыми и глючными после такой репликации, и в будущем подобная ситуация так же может повториться. резервные копии необходимы, но мало того, чтобы просто были резервные копии. потому что даже имея различных 1000 серверов с резервными копиями можно потерять данные в результате программной ошибки в коде OpenZFS, если все эти резервные копии создаются с помощью одной и той же технологии и с помощью одного и того же софта, через полные/инкрементальные zfs send | zfs receive как можно решить эту проблему? мне пока что видится только два возможных варианта решения проблемы: 1. делать другие резервные копии другим софтом и другими технологиями, как это и рекомендуется по правилу создания резервных копий 3-2-1 или 4-3-2-1. Насколько я понимаю, на сегодня, самый лучший и самый надежный и самый удобный софт для создания резервных копий - это borgbackup и restic. 2. проверять какими-то внешними способами, что резервные копия, создаваемые с помощью zfs snapshots на source server и на destination server идентичны между собой и совпадают с точностью до байта. обычно для этого используют rsync и об этом раньше уже говорили в этом чате. Но теоретически - есть и другой способ - это посчитать контрольную сумму SHA-512, SHA-256 или BLAKE3 от содержимого source zfs snapshot и от содержимого destination zfs snapshot, и если эти две контрольные суммы совпадают - тогда почти что со 100% уверенностью можно будет предположить, что искажения данных отсутствуют и на этот раз нам повезло и никакая ошибка в коде OpenZFS не повредила данные при репликации снапшотов с помощью zfs send | zfs receive для zvol датасетов - все более-менее просто - придется изменить snapdev=hidden на snapdev=visible и тогда можно просто посчитать контрольную сумму от содержимого блочного устройства, с первого и до последнего байта. А для filesystem датасетов - все одновременно и проще и сложнее. Проще - потому что можно получить прямой доступ к содержимому снапшота через скрытый каталог .zfs и для этого не надо будет менять properties, но труднее - потому что нет простого способа прочитать содержимого filesystem snapshot с первого и до последнего байта, и такой "образ" содержимого снапшота придется делать самостоятельно из того что видно в скрытом каталоге .zfs - я пока что не нашел как можно в OpenZFS увидеть filesystem snapshot в виде одного потока байт, по аналогии с тем как можно увидеть содержимое zvol snapshot.

первый способ - хороший, когда данных не очень много. но первым способом действовать будет грустно, когда большие объемы данных, на десятки и сотни терабайт. Потому что в этом случае создание резервных копий средствами zfs send | zfs receive работает просто идеально - снапшот создается буквально за секунду и передача инкрементального диффа по сети занимает буквально несколько минут, так что можно делать снапшоты даже раз в час, и таким образом иметь более свежие резервные копии на бэкапных серверах. Но учитывая большое количество уже обнаруженных ранее ошибок в коде OpenZFS, которые приводят к data corruption - это достаточно большой риск, делать резервные копии данных с помощью одной единственной технологии zfs send | zfs receive - но десятки и сотни терабайт данных пропускать через borgbackup и restic - это может быть значительно медленнее, чем почти что мгновенное создание снапшотов и почти что мгновенная их репликация по сети. второй способ - будет, наверное, создавать большую нагрузку на процессор и на source и на destination серверах, но зато не будет требовать дополнительное место на диске, как в случае с borgbackup и restic. По сути - это будет некоторым аналогом ECC памяти, позволяя оперативно обнаруживать повреждение данных через ошибки в коде OpenZFS. А использование для создания резервных копий единственной технологии zfs send | zfs receive будет равносильно использованию на сервере памяти без ECC - так что ошибки и искажения не будут обнаружены. очень много ошибок есть везде - и в hardware - процессорах Intel / AMD, и в software - в ядре Linux и в коде OpenZFS. В ядре Linux - ищут варианты улучшения ситуации, но со всем остальным - все достаточно грустно, как с ошибками в процессорах - регулярно находят все новые и новые ошибки. Да и качество кода OpenZFS очень далеко от идеального, сейчас на OpenZFS github открыто 1431 issues, и их число продолжает только увеличиваться со временем. Но не смотря на все свои недостатки - пока что OpenZFS во многих ситуациях является наилучшим выбором в качестве файловой системы для сервера и других вариантов, которые были бы лучше за OpenZFS просто нет. По крайней мере, нет в виде open source кода, который можно свободно и бесплатно использовать на своем сервере.

Что происходит?)

Хамство с какой целью и по какой причине? Хамство имеет в основе психологические причины: хамы пытаются ощутить собственную важность, уничтожая достоинство жертвы. При помощи хамства люди стараются манипулировать другими или оказывать на них давление, чтобы прийти к личной выгоде. «Нередко такое поведение представляет собой механизм защиты, хамство бывает от страха или неуверенности, таким образом человек переносит акценты с имеющихся у него недостатков либо, наоборот, привлекает к себе внимание, пусть и неблагочестивым поведением. Хамы сами страдают от своих действий, вредя своему эмоциональному и психологическому благополучию», — говорят психологи. Хамство может иметь открытую форму — проявляясь в грубости и насмешках, или скрытую — являясь пассивно-агрессивным поведением. Психологическая причина хамства бывает в: • низкой самооценке — хамство является компенсацией негативных ощущений, создает иллюзорные контроль и власть; • эмоциональной реакции — при помощи хамства человек может снизить отрицательную энергию от какого-то события или действия, вызвавшего гнев или стресс; • желании властвовать и контролировать — через хамское поведение демонстрируется доминирующая позиция, сила и важность; • зависти и ревности — агрессивное поведение к жертве может проявиться, если хам ревнует или завидует, его цель — в подрыве достижений и качеств оппонента; • недостатке эмпатии — если человеку сложно понять переживания и эмоции другого человека, он может проявить бесчувственность либо хамство; • социокультурных факторах — среда, где пришлось расти человеку, соприкосновение его с теми или иными культурными и социальными нормами формируют поведенческие паттерны, то есть человек может хамить по привычке, он просто не знает, что взаимодействовать можно иначе.

сообщение выглядит как оффтоп, не приветствуется.

В документации к OpenZFS рекомендуется использовать имена дисков /dev/disk/by-id/ - например: /dev/disk/by-id/nvme-SAMSUNG_MZQL23T8HCLS-00A07_S64HNE0R803057 тут же сразу видно и тип накопителя, и название производителя диска, и его модель и его серийный номер. очень удобный способ адресовать диски, и при этом - имена всегда уникальны и никогда не изменяются. почему бы не использовать именно этот метод, как и рекомендуется в документации? тем более, что имена дисков в /dev/disk/by-id/ - это просто симлинки на все те же самые /dev/sdX и /dev/nvmeX Вы же не получаете никаких преимуществ, используя постоянно меняющиеся имена дисков /dev/sdX - тем более, что в случае выхода диска из строя невозможно будет быстро определить, какой именно диск надо менять - это неудобно. Вот у меня на серваке был прикол только недавно. Он местами перепутал винты буквами и потерял винт, потому что у него другая буква. А он был подключен. Просто буква съехала. И приходилось делать замену))) Очень продуманно там не может съехать буква, имена дисков в /dev/disk/by-id/ статичны и никогда не меняются. имена дисков /dev/sdX можно использовать только для тестирования, но не для production. Вы сами себе создаете проблемы на ровном месте, не читая документацию и не делая, как там рекомендуется. Она сама должна сканировать и искать винты свои по всем шинам, а не опираться тупо на ось. по умолчанию - включен сервис zfs-import-cache.service # systemctl status zfs-import-cache.service если для каких-то странных и не понятных целей надо, чтобы не использовался файл /etc/zfs/zpool.cache - то тогда имеет смысл выключить сервис zfs-import-cache.service и включить сервис zfs-import-scan.service # systemctl status zfs-import-scan.service но в результате будет - замедление импорта zpool, потому что zfs тогда придется сканировать все диски, а это может быть очень не быстрый процесс, если дисков в сервере много. Вас разве кто-то насильно принуждает пользоваться файловой системой OpenZFS ? Вообще не понятно, в чем проблема? Если не хотите - не пользуйтесь.

zfs ниасиливает делать это в эн потоков, где эн=колво дисков?

zfs ниасиливает делать это в эн потоков, где эн=колво дисков?

никогда в подробностях не интересовался тем, как работает # zpool import -o cachefile=none если вам интересно - узнайте как это работает и расскажете нам подробности. P.S. логично же, что режим # zpool import -c /etc/zfs/zpool.cache будет работать быстрее, чем # zpool import -o cachefile=none иначе в файле /etc/zfs/zpool.cache просто нет смысла. сколько именно будет ускорения в процентах - я не измерял, но ускорение при использовании /etc/zfs/zpool.cache точно будет, и на больших zpool с большим количеством дисков (десятки и сотни HDD) это должно быть хорошо заметно. вполне может быть и так, что код, делающий zpool import не многопоточный, поскольку писать и отлаживать его гораздо проще будет в таком случае, а выполняется он достаточно редко - только при старте сервера, поэтому - я бы не стал такой код делать многопоточным, иначе это будет просто Premature Optimization. Но как именно это сделано в коде zfs - не выяснял, это мне не настолько интересно, чтобы рыться в исходниках или ставить эксперименты на эту тему. Если вам это интересно - выясните и расскажете. zfs ниасиливает делать это в эн потоков, где эн=колво дисков? скорее всего, что причина не в этом. HDD при старте потребляют очень много для того, чтобы раскрутить диски, и поэтому в серверах с большим количеством HDD все они одновременно стартовать не могут - просто не хватит мощности блока питания. И поэтому - запускаются и раскручиваются по очереди. И попытка zfs import одновременно все диски сканировать и читать не смогла бы работать из-за этой особенности HDD. Именно поэтому программисты, которые создавали zfs и не пытались даже, как я предполагаю, реализовывать многопоточное сканирование одновременно всех HDD сервера при старте, потому что это просто физически невозможно на серверах с большим и очень большим количеством HDD. и поэтому - файл /etc/zfs/zpool.cache и является наиболее оптимальным и самым целесообразным и самым быстрым решением. исходная файловая система zfs, созданная еще в Sun Microsystems была создана программистами и инженерами очень высокого уровня квалификации, и дизайн этой файловой системы очень крутой - так что если ими было принято какое-то решение - как правило - оно было самым оптимальным и самым целесообразным в тот момент времени. Тривиальных ошибок они не делали в дизайне файловой системы - по крайней мере, я не смог найти и не смог увидеть ни одной. сейчас многие моменты в дизайне файловой системы можно будет сделать лучше, что и пытаются сделать в btrfs и в bcachefs, но на тот момент, на момент создания файловой системы zfs - это было что-то такое, чего раньше не было, в моем понимании - это примерно как первый полет в космос, который совершил Юрий Гагарин. Хотя сейчас - это уже можно сделать еще лучше, при современном уровне развития технологий и компьютерной техники.

Это может не сильно важно, но стоит наверное привести к стандарту

Попробовал. Убрал backports, откатил на стандарт и ядра, и zfs. Но пул в такой конфигурации импортировать не получается: zpool import -d /dev/disk/by-id db This pool uses the following feature(s) not supported by this system: com.klarasystems:vdev_zaps_v2 cannot import 'db': unsupported version or feature Зачем zfs применила эту фичу, если я её не просил 🙈? Пришлось возвращаться на backports. PS Вообще я бы ожидал, что при апгрейде системы данные, с которыми система работает (пулы/датасеты) оставались для совместимости неизменными. Иначе эти пулы при необходимости уже на какую-нибудь обкатанную систему, которую не хочется трогать, уже и не перенесешь.

Попробовал. Убрал backports, откатил на стандарт и ядра, и zfs. Но пул в такой конфигурации импортировать не получается: zpool import -d /dev/disk/by-id db This pool uses the following feature(s) not supported by this system: com.klarasystems:vdev_zaps_v2 cannot import 'db': unsupported version or feature Зачем zfs применила эту фичу, если я её не просил 🙈? Пришлось возвращаться на backports. PS Вообще я бы ожидал, что при апгрейде системы данные, с которыми система работает (пулы/датасеты) оставались для совместимости неизменными. Иначе эти пулы при необходимости уже на какую-нибудь обкатанную систему, которую не хочется трогать, уже и не перенесешь.

Если мне память не изменяет, то при апгрейде пула есть предупреждение, что фичи обновятся/включатся

И это поведение можно отключить

Если мне память не изменяет, то при апгрейде пула есть предупреждение, что фичи обновятся/включатся

А в какой момент могло быть такое предупреждение? Вот добавил я backports, запустил установку (которую ведь делает система, про фичи zfs ничего не знающая) - никаких предупреждений. Импортирую пул - тоже никаких предупреждений. А потом вдруг оказывается, что он уже "улучшен до потери совместимости" 😞

Попробовал. Убрал backports, откатил на стандарт и ядра, и zfs. Но пул в такой конфигурации импортировать не получается: zpool import -d /dev/disk/by-id db This pool uses the following feature(s) not supported by this system: com.klarasystems:vdev_zaps_v2 cannot import 'db': unsupported version or feature Зачем zfs применила эту фичу, если я её не просил 🙈? Пришлось возвращаться на backports. PS Вообще я бы ожидал, что при апгрейде системы данные, с которыми система работает (пулы/датасеты) оставались для совместимости неизменными. Иначе эти пулы при необходимости уже на какую-нибудь обкатанную систему, которую не хочется трогать, уже и не перенесешь.

по дефолту фичи не апгрейдятся. уж точно на дебиане так.

скорее всего руками сделали zpool upgrade

по дефолту фичи не апгрейдятся. уж точно на дебиане так.

Ну на дебиане это и было. Я уж точно ничего не просил.

скорее всего руками сделали zpool upgrade

Никогда root@S04:~# history | grep "zpool upgrade" 502 history | grep "zpool upgrade"

Никогда root@S04:~# history | grep "zpool upgrade" 502 history | grep "zpool upgrade"

лучше историю в zdb смотреть. размер истории баш по дефолту коротенький.

лучше историю в zdb смотреть. размер истории баш по дефолту коротенький.

ой или zfs history кажись

лучше историю в zdb смотреть. размер истории баш по дефолту коротенький.

Ну и на backports я совсем недавно то переходил, особо больше ничего и не делал. А главное, и не собирался пулы апгрейдить.

ой или zfs history кажись

zpool все-таки. Был один год назад. А на backports в декабре только перешел. root@S04:~# zpool history db | grep upgrade 2024-04-13.17:08:16 zpool upgrade db

root@S04:~# zpool upgrade This system supports ZFS pool feature flags. All pools are formatted using feature flags. Every feature flags pool has all supported and requested features enabled.

вот по датам рядом

вот по датам рядом

Рядом с чем? Апгрейд в апреле 2024. backports в декабре 2024. Возврат на ядро linux-image-6.1.0-31-amd64 и установка соответствующей zfs в феврале 2025

Рядом с чем? Апгрейд в апреле 2024. backports в декабре 2024. Возврат на ядро linux-image-6.1.0-31-amd64 и установка соответствующей zfs в феврале 2025

Ты видимо из бэкпортов ставишь слишком старую версию

Ты видимо из бэкпортов ставишь слишком старую версию

Хотя нет, отмена

вот по датам рядом

Эта фича смёрджилась в 2.2.7

Ты видимо из бэкпортов ставишь слишком старую версию

Из бэкпортов ставилась в декабре zfs-2.2.6-1~bpo12+3, zfs-kmod-2.2.6-1~bpo12+3 и с ней всё работало. Это когда я с бэкпорта ушел - не стало импортироваться. PS сейчас, когда снова на backports вернулся - стала zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1

Из бэкпортов ставилась в декабре zfs-2.2.6-1~bpo12+3, zfs-kmod-2.2.6-1~bpo12+3 и с ней всё работало. Это когда я с бэкпорта ушел - не стало импортироваться. PS сейчас, когда снова на backports вернулся - стала zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1

Мне интересно не собирали 2.2.6-1 bpo12+3 с мастер ветки в какой-то момент

Йеп

https://github.com/openzfs/zfs/discussions/15702

Занятно, при direct=always при попытке обновить initramfs такая вот штука. Если переключить на standard, то проблема исчезает. мб это дебианпроблемы. т.к. гуглинг ничего не дал. при переключении между direct=always и direct=standard все что находится за пределами ядра остается идентичным - меняется только поведение модуля ядра zfs, так что причина этого глюка находится на стороне ядра, в модуле zfs. И если дебиановцы не напихали в свою сборку OpenZFS каких-то специфических только для дебиана патчей, как они это умеют делать (например, CVE-2008-0166) - то причина этой ошибки - все-таки в коде OpenZFS. и возможно issue в багтрекере на GitHub помог бы лучше понимать разработчикам OpenZFS масштабы этой проблемы, и может быть они смогли бы каким-то образом еще раз, более внимательно посмотреть на свой код Direct IO Support #10018. или - хотя бы можно будет в документации указать, какой workaround можно применить, чтобы не было проблем. P.S. похожая ситуация на Fedora: https://github.com/openzfs/zfs/issues/17027 возможно, причина проблемы в точности та же самая.