@gmelikov @simubishi @neurox А мы будем что-то делать с chatgpt ботом в чате?

А скрипты вызывают необходимость держать специально заточенный под зфс initramfs потому что файловая система zfs не может быть вкомпилирована внутрь ядра Linux - это делать запрещено. пока модуль zfs в ядро не загружен - тогда само ядро Linux про zfs ничего не знает и работать с ним не умеет. "в случае btrfs" ситуация другая, потому что btrfs входит в состав ядра и ядро про файловую систему btrfs знает. А скрипты вызывают необходимость держать специально заточенный под зфс initramfs это вызывают не скрипты, а несовместимость лицензий GPLv2 и CDDL - это было решение компании Sun Microsystems - открыть исходный код файловой системы ZFS под лицензией CDDL а не под лицензией GPLv2. Да и Линус Торвальдс "не рекомендовал пользоваться модулем zfs из-за несовместимости лицензий CDDL и GPLv2". это - как раз и есть отрицательные побочные эффекты того, что приходится "жить out of tree относительно кода ядра". хотя, положительных эффектов от того, что приходится "жить out of tree относительно кода ядра" наверное все-таки больше - потому что можно поставить любую версию zfs на любую версию ядра, а не довольствоваться тем, что находится внутри ядра и дается в готовом виде - для простых файловых систем ext4 / xfs - это не проблема, а для zfs такое отсутствие гибкости - достаточно неудобно, когда руки связаны и нет возможности самому выбирать версию zfs. так что, похоже на то, что без дополнительных скриптов в initramfs монтировать рутовый раздел zfs сразу ядром Linux никак не получится сейчас и в будущем - я не понимаю, как это можно было бы сделать, пока zfs под лицензией CDDL. https://www.opennet.ru/opennews/art.shtml?num=52164 Напомним, что код ZFS распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFS on Linux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости проектом "ZFS on Linux" было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.

хотя хз

А скрипты вызывают необходимость держать специально заточенный под зфс initramfs потому что файловая система zfs не может быть вкомпилирована внутрь ядра Linux - это делать запрещено. пока модуль zfs в ядро не загружен - тогда само ядро Linux про zfs ничего не знает и работать с ним не умеет. "в случае btrfs" ситуация другая, потому что btrfs входит в состав ядра и ядро про файловую систему btrfs знает. А скрипты вызывают необходимость держать специально заточенный под зфс initramfs это вызывают не скрипты, а несовместимость лицензий GPLv2 и CDDL - это было решение компании Sun Microsystems - открыть исходный код файловой системы ZFS под лицензией CDDL а не под лицензией GPLv2. Да и Линус Торвальдс "не рекомендовал пользоваться модулем zfs из-за несовместимости лицензий CDDL и GPLv2". это - как раз и есть отрицательные побочные эффекты того, что приходится "жить out of tree относительно кода ядра". хотя, положительных эффектов от того, что приходится "жить out of tree относительно кода ядра" наверное все-таки больше - потому что можно поставить любую версию zfs на любую версию ядра, а не довольствоваться тем, что находится внутри ядра и дается в готовом виде - для простых файловых систем ext4 / xfs - это не проблема, а для zfs такое отсутствие гибкости - достаточно неудобно, когда руки связаны и нет возможности самому выбирать версию zfs. так что, похоже на то, что без дополнительных скриптов в initramfs монтировать рутовый раздел zfs сразу ядром Linux никак не получится сейчас и в будущем - я не понимаю, как это можно было бы сделать, пока zfs под лицензией CDDL. https://www.opennet.ru/opennews/art.shtml?num=52164 Напомним, что код ZFS распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFS on Linux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости проектом "ZFS on Linux" было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.

А скрипты вызывают необходимость держать специально заточенный под зфс initramfs потому что файловая система zfs не может быть вкомпилирована внутрь ядра Linux - это делать запрещено. пока модуль zfs в ядро не загружен - тогда само ядро Linux про zfs ничего не знает и работать с ним не умеет. "в случае btrfs" ситуация другая, потому что btrfs входит в состав ядра и ядро про файловую систему btrfs знает. А скрипты вызывают необходимость держать специально заточенный под зфс initramfs это вызывают не скрипты, а несовместимость лицензий GPLv2 и CDDL - это было решение компании Sun Microsystems - открыть исходный код файловой системы ZFS под лицензией CDDL а не под лицензией GPLv2. Да и Линус Торвальдс "не рекомендовал пользоваться модулем zfs из-за несовместимости лицензий CDDL и GPLv2". это - как раз и есть отрицательные побочные эффекты того, что приходится "жить out of tree относительно кода ядра". хотя, положительных эффектов от того, что приходится "жить out of tree относительно кода ядра" наверное все-таки больше - потому что можно поставить любую версию zfs на любую версию ядра, а не довольствоваться тем, что находится внутри ядра и дается в готовом виде - для простых файловых систем ext4 / xfs - это не проблема, а для zfs такое отсутствие гибкости - достаточно неудобно, когда руки связаны и нет возможности самому выбирать версию zfs. так что, похоже на то, что без дополнительных скриптов в initramfs монтировать рутовый раздел zfs сразу ядром Linux никак не получится сейчас и в будущем - я не понимаю, как это можно было бы сделать, пока zfs под лицензией CDDL. https://www.opennet.ru/opennews/art.shtml?num=52164 Напомним, что код ZFS распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFS on Linux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости проектом "ZFS on Linux" было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.

Нет, это прям вырезки из chatgpt

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

А скрипты вызывают необходимость держать специально заточенный под зфс initramfs потому что файловая система zfs не может быть вкомпилирована внутрь ядра Linux - это делать запрещено. Это дикая сумасшедшая чушь. Во-1, зфс прекрасно вкомпилируется в ядро, причём штатно. Ррраз, configure -- и в конфигураторе ядра появляется галочка "zfs". И потом оно даже работает. Во-2, никакая, ну вот вообще никакая лицензия НЕ ЗАПРЕЩАЕТ так делать. Запрещает потом результат в бинарной форме раздавать, да, наверное. Но у себя на локалхосте -- ну вот ни разу. Запрещено - не технически, а "юридически", из-за несовместимости лицензий Linux и zfs. Поэтому ни один дистрибутив и не поставляет в бинарном виде zfs вкомпилированного внутрь ядра Linux. Отсюда и "необходимость держать специально заточенный под зфс initramfs". Откуда ядро Linux может узнать как ему примонтировать рутовый раздел на zfs, пока модуль zfs не загружен в ядро?

ubuntu передаёт привет

ubuntu передаёт привет

А вот какие есть варианты сверить снапшоты (посланный с принятым)? вариант 1 — пофайлово другие?

А вот какие есть варианты сверить снапшоты (посланный с принятым)? вариант 1 — пофайлово другие?

Так снапшот же атомарная сущность, он либо передался, либо нет

ага и файлики занулились как в недавних багах

если хотите явно перепроверить не доверяя коду zfs (что в целом полезно для своего внутреннего параноика) - то да, тем же rsync можно в dry run чекнуть разницу. А так на уровне ZFS если снап принялся, то т.к. он иммутабелен то и поменять его нельзя, т.е. какой принят такой и есть, дальше только scrub юзать штатно целостность блоков проверять. Не помню кстати идёт ли сверка снапов по какой-то чексумме из merkle tree или просто по idу, кажется по idу (когда проверяется можно ли инкрементально принять снапшот). Если переживаете за целостность стрима - емнип в потоке от zfs send есть чексуммы и базовая проверка идёт итак.

рсинк симлинки сравнивать будет по файлам на которые они ведут или просто по заданным в ним путям? пушо п.1 -- неверно.

Так они нулились в cp

? А зачем тебе сравнивать симлинки. Типо, rsync -a --dry-run и погнали

а не -ac ?

--copy-links --links

так мне ж сравнить надо а не скопировать их

так что по-твоему делает rsync когда докопировывает поток?

допустим. а как именно решается такой же симлинк или другой?

Если он есть и ведёт на тот же файл, тот же Если ты не задал отдельно --copy-links, тогда копируется файл вместо линка, поэтому он выдаст *разные файлы*, если встретит линк

'на тот же файл' - а на бекап-сервере симлинки никуда не ведут обычно

Я не сказал, что он проверяет конечный файл, только *путь*

похоже опять словил PANIC: zfs: adding existent segment to range tree https://dpaste.com/4U2LXT8CY

Подскажите, как можно починить пул При попытках записать данные, сделать экспорт или запустить scrub, процесс намертво зависает через некоторое время Никаких ошибок, кроме PANIC: zfs: adding existent segment to range tree в момент загрузки модуля нет Опции vfs.zfs.recover=1 vfs.zfs.zil.replay_disable=1 vfs.zfs.spa.load_verify_data=0 vfs.zfs.spa.load_verify_metadata=0 не особо помогают, в определённый момент работа с пулом виснет, опять же без каких-либо ошибок в логах Ядро 6.12.10 zfs 2.3.0 Все началось с момента, когда попытался скопировать на пул файл 400Гб

Ну, поехали разбираться. smartctl что говорит про все диски?

Какая версия zfs? какие пулы, какие диски? Виртуалка или физическая машина?

Ядро 6.12.10 zfs 2.3.0 Железная машина, подключено к hba

Интересно, такая ошибка была но должна быть пофиксена уже давно. сколько место на пуле занято?

Да, но тикет открыт Скорее всего тут только перенос данных

Интересно, такая ошибка была но должна быть пофиксена уже давно. сколько место на пуле занято?

По месту, процентов 60 точно Уже подвис пул

100% только перенос данных

и никаких других ошибок Может ли тут быть причиной какое-то более раннее повреждение данных? Есть ли варианты как-то выяснить причину?

Нет Год назад делал до этого

Память в сервере с ECC?

Да

Там есть несколько поврежденных файлов 50-100Гб, после прогона scrub, два дня назад

Возможно ли скопировать параметры датасетов?

Да я думаю как переносить данные) В тот раз мне как-то удалось починить пул