короче я вопрос решил. вроде как и нечго уже обсуждать.

короче я вопрос решил. вроде как и нечго уже обсуждать.

Как решил то?)

Как решил то?)

смонтировал в /root, ввел exit

вот вопрос бы в том куда монтировать, чтоб загрузка оси пошла

Гм.. по моему очевидно что в корень..

Гм.. по моему очевидно что в корень..

корень это /

Гм.. по моему очевидно что в корень..

не, в initramfs есть момент когда реальный корень системы в, например, /root монтируется. А в / сам initramfs в это время

а потом есть что-то вроде switch_root

а потом есть что-то вроде switch_root

пробовал по гентушной вики. какая-то километровая ругань вываливалась при запуске init.

пробовал по гентушной вики. какая-то километровая ругань вываливалась при запуске init.

ну в rescue главное примонтировать реальный root куда он хочет, дальше ctrl+d и оно продолжит (если именно на маунте проблема была)

вот только понять не могу а что собственно мешает монтированию в автоматическом режиме. я конечно сам виноват, решил потыкать новое ведро от liquorix )

вродь ничего полезного на первый взнляд

вот только понять не могу а что собственно мешает монтированию в автоматическом режиме. я конечно сам виноват, решил потыкать новое ведро от liquorix )

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

(пуст в initramfs или не актуальный)

(пуст в initramfs или не актуальный)

а каким образом cache попадает в initramfs ?

ставил в соответствии с этой докой: https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html update-initramfs -c -k all не помогает починить автозагрузку

вчера поставил новое ведро и перестало грузиться. в истории апта ничего страшного: Start-Date: 2021-09-15 23:50:52 Commandline: apt install linux-image-5.11.0-21.2-liquorix-amd64 linux-headers-5.11.0-21.2-liquorix-amd64 Requested-By: uzer (1000) Install: libelf-dev:amd64 (0.185-2, automatic), linux-headers-5.11.0-21.2-liquorix-amd64:amd64 (5.11-36.1~bullseye), libbabeltrace1:amd64 (1.5.8-1+b3, automatic), linux-image-5.11.0-21.2-liquorix-amd64:amd64 (5.11-36.1~bullseye) End-Date: 2021-09-15 23:54:15

ставил в соответствии с этой докой: https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html update-initramfs -c -k all не помогает починить автозагрузку

а, если правильно помню, по этому пути критично выполнение этого vi /etc/default/grub # Set: GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian" ставится zfs-initramfs и он использует это указание для импорта и маунта.

а дальше только копать почему не импортнулся пул

и вообще пытались ли его импортнуть

а, если правильно помню, по этому пути критично выполнение этого vi /etc/default/grub # Set: GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian" ставится zfs-initramfs и он использует это указание для импорта и маунта.

от оно че. похоже я когда-то умудрился снести /etc/default/grub

и вот сейчас всплыло

Уважаемые, а вот тупой вопрос. Искал в инете, везде рецепты только для ЕХТ разных а для нашей ФС все пишут - забей, она сама разберется. Начал отваливаться диск из пула. Ошибки чтения. Скорее всего БЭДы. А как с учетом ZFS их проверить и исправить правильно?

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

Что разберётся сама - не соврали, она обработает эту ошибку, при этом укажет, что диск достоин внимания.

zpool status покажет все проблемы, если есть потери - тоже явно укажет на них

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

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

Пометка секторов как битые в целом в ней не предусмотрена. Если данные дороги, лучше под замену.

Можно проанализировать Смарт диска, может он сможет указать на источник проблемы. По результатам и действовать.

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

Не диск отваливается, а пул его выкидывает из за превышения порога ошибок чтения.

А, у меня такое было. Там можно скинуть счетчик ошибок

Но это все равно не отменяет факта, что рано или поздно диск рискует помереть с концами

Что разберётся сама - не соврали, она обработает эту ошибку, при этом укажет, что диск достоин внимания.

Вот теперь вопрос, как то по особому надо обращаться с диском из за ZFS или стандартными средствами как обычно проверять? Опять же, в Проксмокс из коробки нет бэдблокс и из репы не ставится почему-то))

zpool status покажет все проблемы, если есть потери - тоже явно укажет на них

Да показывает. Суть вопроса, как его поремапить то?

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

Антикварный САС на 146Гб))) Их таких 5шт в пуле)) Новфй дорогущий и не стоит покупать, а Б\У нет гарантии что не такой же будет((

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

Все передернул. И кабеля, и сами диски из корзины вынимал-вставлял.

Пометка секторов как битые в целом в ней не предусмотрена. Если данные дороги, лучше под замену.

Пока тестовая лаба. Хотел поиспользовать как резервный сервер. С переодическим накатыванием бэкапов виртуалок туда. Чтоб эдакий ручной НА ))

Можно проанализировать Смарт диска, может он сможет указать на источник проблемы. По результатам и действовать.

Почему-то у него одного очень много исправленных ошибок передачи, по сравнению с соседями, и есть неисправленные. На кабель грешить не получится, там экспандер. Корзина на 6 дисков всего 2я кабелями подключена.

А, у меня такое было. Там можно скинуть счетчик ошибок

Скидывал. Ресильвер проходит. Какое то время ОК а потом опять его выкидывает.

Но это все равно не отменяет факта, что рано или поздно диск рискует помереть с концами

Само собой. Подозрительно то, что до этого в железном рэйде они все работали лет 15 и "ни единого разрыва". А сняли сервер с работы, я прошил контроллер в НВА и поднял ZFS и буквально в течении месяца его 2 раза уже выбило))

По-моему тут или низкоуровневый ремап (mhdd или что там сейчас актуально), или диск менять. "Софтварные" варианты не помогут

По-моему тут или низкоуровневый ремап (mhdd или что там сейчас актуально), или диск менять. "Софтварные" варианты не помогут

Ну MHDD это как бы тоже "софтварный" )) он просто находит сектор который плохо читатется и начинает его пилить пока софт прошивки не прочухается и не занесет в дефект-лист. И плюс, это САС за контроллером. Ни виктория ни МШДД их не видят. Smartcrl даже таблицу смарт не показывает. Говорит нечего показывать))

Тогда ты лучше меня знаешь, что можно сделать. Скорее всего ничего иного тут не придумать

Ну, я думал может какие есть специальные рецепты. Тапа как в ЕХТ когда находишь бэды а потом фсчеку передаешь эти бэды списком, и он в самой файловой помечает чтобы эти блоки не трогала система.

Ну, я думал может какие есть специальные рецепты. Тапа как в ЕХТ когда находишь бэды а потом фсчеку передаешь эти бэды списком, и он в самой файловой помечает чтобы эти блоки не трогала система.

нет, в zfs такого маппинга нет, тут принято при первой ошибке оборудование менять, ибо на сбойном смысла работать мало

(когда важны данные)

Ну MHDD это как бы тоже "софтварный" )) он просто находит сектор который плохо читатется и начинает его пилить пока софт прошивки не прочухается и не занесет в дефект-лист. И плюс, это САС за контроллером. Ни виктория ни МШДД их не видят. Smartcrl даже таблицу смарт не показывает. Говорит нечего показывать))

не в hba режиме чтоли?

печаль

Само собой. Подозрительно то, что до этого в железном рэйде они все работали лет 15 и "ни единого разрыва". А сняли сервер с работы, я прошил контроллер в НВА и поднял ZFS и буквально в течении месяца его 2 раза уже выбило))

Так вы сами отвечаете на ваши вопросы - сервер после 15 лет работы начали вдруг включать и выключать, перешили контроллер. У меня был случай когда по всем дискам в пуле произвольности начинали сыпаться ошибки. Перешил прошивку в hba- проблема ушла

а с чего вообще контроллер перешить надумали ? мб сначала проблемы появились, потом перешили ?

нет, в zfs такого маппинга нет, тут принято при первой ошибке оборудование менять, ибо на сбойном смысла работать мало

В хардварном режиме все было пучком.

не в hba режиме чтоли?

Как контроллер как раз сейчас в хба режиме.

Так вы сами отвечаете на ваши вопросы - сервер после 15 лет работы начали вдруг включать и выключать, перешили контроллер. У меня был случай когда по всем дискам в пуле произвольности начинали сыпаться ошибки. Перешил прошивку в hba- проблема ушла

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

а с чего вообще контроллер перешить надумали ? мб сначала проблемы появились, потом перешили ?

Потому что зфс лучше прямой доступ к диску, потому на хба и перешил.

Ладно, спасибо. Ответ уже дали, нет специальных средств, будем мучить обычными)

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

Что именно я по диагонали читал? То что сервер с дисками проработал 15 лет, потом стали экспериментировать, перешили контроллер и начались проблемы? Даже если это не контроллер - что удивляет в том что спустя 15 лет «вдруг» начались проблемы с диском? Или по вашему они вечные?

Хоспадя. Просто имелось ввиду что железный Феликс, тобишь рейд, с замшелой прошивкой, более толерантен оказался к дискам чем свежая zfs

Фсё. На этом прошу закончим.

а где можно почитать как в zfs устроено слежение за шаренными блоками данных (например в снапшотах и клонах)? чото вспомнилось что в zfs нельзя быстро мувать-копировать файлы между датасетами, а в btrfs можно (cp --reflink=always)

а где можно почитать как в zfs устроено слежение за шаренными блоками данных (например в снапшотах и клонах)? чото вспомнилось что в zfs нельзя быстро мувать-копировать файлы между датасетами, а в btrfs можно (cp --reflink=always)

Копировать то почему нельзя? Мувать, ок там да, удаление мрачное

Копировать то почему нельзя? Мувать, ок там да, удаление мрачное

ну пушо копирование между датасетами это настоящее копирование, перелив данных из 1 файла в другой

--reflink=always в zfs не работает

ну пушо копирование между датасетами это настоящее копирование, перелив данных из 1 файла в другой

А как между датасетами может быть рефлинк? Это ж разные. Внутри датасета ж все ок

А как между датасетами может быть рефлинк? Это ж разные. Внутри датасета ж все ок

ну в btrfs между subvolume'ами прекрасно может быть

ну в btrfs между subvolume'ами прекрасно может быть

Смахивает на симлинки

И что будет, если оригинал удалить?

И что будет, если оригинал удалить?

вот я как раз оригинал удалил. все ок с файлами )

cp -rav --reflink=always копировал

вот я как раз оригинал удалил. все ок с файлами )

Хотя надо глянуть, там что-то сгоряка на эту тему писала

Может тоже есть такое

ну в btrfs между subvolume'ами прекрасно может быть

только сегодня в багтрекере openzfs видел что нельзя https://github.com/openzfs/zfs/issues/405#issuecomment-923653241

ну и тема там же про reflink в zfs

А как между датасетами может быть рефлинк? Это ж разные. Внутри датасета ж все ок

кто сказал, что внутри датасета можно рефлинки делать?

кто сказал, что внутри датасета можно рефлинки делать?

You can quickly copy large files using the cp -z command. The –z option copies the metadata associated with each record, rather copying the metadata and all of the data

это откуда?

кто сказал, что внутри датасета можно рефлинки делать?

да и внутри нельзя вроде...

в текущем debian cp ничего не знает о -z

только сегодня в багтрекере openzfs видел что нельзя https://github.com/openzfs/zfs/issues/405#issuecomment-923653241

между маунтпойнтами я не пробовал. между subvol'ами в одном маунтпойнте - на ура.