И никто не думает про вим, интересно

еще есть Urbackup - он хоть использует zfs снимки и не мучает систему обходом

И никто не думает про вим, интересно

vim ?

vim ?

Не совсем))

Не совсем))

Veeam - ффтопку

Veeam - ффтопку

Ну не скажи, он точно удобнее чем commvault для малых/средних инфраструктур

@ialebedev ты в r/w-то стабильный смог примонтироваться ? Чем дело закончилось ?

@ialebedev ты в r/w-то стабильный смог примонтироваться ? Чем дело закончилось ?

Пока бэкаплю

Там порядка 20 Тб

@ialebedev ты в r/w-то стабильный смог примонтироваться ? Чем дело закончилось ?

Кстати, спрошу наперед. Допустим, я смог откатиться на предыдущую версию zfs, и смог смонтировать на rw. Как мне проверить, действительно ли в нем не пострадала инфа и насколько пул в целости?

Так то в режиме ro визуально все норм. Файлы целые

Кстати, спрошу наперед. Допустим, я смог откатиться на предыдущую версию zfs, и смог смонтировать на rw. Как мне проверить, действительно ли в нем не пострадала инфа и насколько пул в целости?

scrub?

scrub?

Ну собственно я и спрашивал. Scrub или что-то ещё.

Кстати, спрошу наперед. Допустим, я смог откатиться на предыдущую версию zfs, и смог смонтировать на rw. Как мне проверить, действительно ли в нем не пострадала инфа и насколько пул в целости?

Я с некоторых пор строю текстовое древо через ncdu и потом сравниваю после работ

Я поскольку не сильно ещё опытен в ZFS поэтому, и задаю возможно иногда глупые вопросы))

Я с некоторых пор строю текстовое древо через ncdu и потом сравниваю после работ

А что! Это кстати, вариант!

Scrub по любому

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

Вопрос немного не по теме ZFS, но может кто знает. Есть NFS шары, которые клиенты монтируют как hard, через соответствующий systemd маунт сервис. Если по каким-то причинам шара уходит в офлайн, то все программы что обращались к шаре фризятся, до момента восстановления шары. А можно как-то заставить сервис останавливаться, если шара какое время недоступна? Я не единожды пытался это реализовать, но пока так и не получилось. Ман по этому делу перечитал несколько раз, пробовал и LazyUnmount и ForceUnmount включать в сервисе. Но успеха не добился. В идеале мне нужно, чтобы в случае отваливания шары, чтобы на машине клиента она отмонтровалась, чтобы фриз програм ушел, а когда шара вернётся, она автоматически снова подцеплялась.

Предлагаю почитать про состояние процесса d-state. При таком способе, насколько помню, при отвале возможен только он. Можно попробовать поиграть с логикой сервиса в условиях более мягкого монтирования.

Вопрос немного не по теме ZFS, но может кто знает. Есть NFS шары, которые клиенты монтируют как hard, через соответствующий systemd маунт сервис. Если по каким-то причинам шара уходит в офлайн, то все программы что обращались к шаре фризятся, до момента восстановления шары. А можно как-то заставить сервис останавливаться, если шара какое время недоступна? Я не единожды пытался это реализовать, но пока так и не получилось. Ман по этому делу перечитал несколько раз, пробовал и LazyUnmount и ForceUnmount включать в сервисе. Но успеха не добился. В идеале мне нужно, чтобы в случае отваливания шары, чтобы на машине клиента она отмонтровалась, чтобы фриз програм ушел, а когда шара вернётся, она автоматически снова подцеплялась.

что насчёт soft?

что насчёт soft?

Честно сказать принципиально разницы не заметил в тестах с soft и hard. Терминал отваливался в итоге и возвращался к жизни. А например dolphin нет. В случае hard, фризились оба и без намека на анфриз

что насчёт soft?

Но вообще конечно хотелось бы в hard режиме решить проблему

Честно сказать принципиально разницы не заметил в тестах с soft и hard. Терминал отваливался в итоге и возвращался к жизни. А например dolphin нет. В случае hard, фризились оба и без намека на анфриз

Это проблема dolphin. Для автоматического монтирования есть automount. Чем принципиален hard?

Это проблема dolphin. Для автоматического монтирования есть automount. Чем принципиален hard?

В смысле autofs?

systemd automount.

А вообще https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-client-config-options

А вообще https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-client-config-options

Ага, спасибо за ссылку. Пошел читать)

я так понял, при смене recordsize на пуле с данными дефрагментатора не предусмотрено? придется повторно переливать ? P.S. этот пул не загрузочный

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

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

ну, вот в моем случае хотелся бы ручной запуск дефрагментатора

Его нет :) Как вариант - заново занести данные, они лягут с новым рекордсайзом, но дефрагментации не будет. Может, будет мнимая дефрагментация, но рандомное чтение так и так сохранится по ряду причин. При записи на пул во время эксплуатации любой мнимый эффект от дефрагментации будет утерян.

Его нет :) Как вариант - заново занести данные, они лягут с новым рекордсайзом, но дефрагментации не будет. Может, будет мнимая дефрагментация, но рандомное чтение так и так сохранится по ряду причин. При записи на пул во время эксплуатации любой мнимый эффект от дефрагментации будет утерян.

так и понял. переливаю заново ~800 ГБ

у меня сейчас так с идентичными данными # zpool list tank2 NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank2 5,44T 810G 4,65T - - 31% 14% 1.23x ONLINE - # zpool list tank3 NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank3 2,72T 775G 1,96T - - 9% 27% 1.09x ONLINE -

Проблемы дефрагментации начинаются от 90-95%

До этого момента их условно нет

Други, можете подсказать, как реимпортнуть пул в режиме rw, если он щас заимпорчен как ro?

Бэкап завершился. Щас буду пробовать возвращать пул в рабочий режим

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

да

заблеклисть модуль

потом подгрузи вручную

сделай рекавери режим

и потом импорт

если у тебя линукс

в логах будет периодически подобное WARNING: zfs: adding existent segment to range tree (offset=a18422c6000 size=4a000)

заблеклисть модуль

Какой именно?

Какой именно?

zfs

чтобы при загрузке системы не было ошибки он же сразу пробует импортнуть и система не загрузится

Не щас система грузится нормально, т.е. я zpool.cache перенес

и он не видит пул при загрузке

Далее я делаю zfs import zdata

и вылезает эта ошибка

раньше она же вылезала при загрузке, при попытке импорта пула

пока я zpool.cache не перенес в другое место

у меня оно просто в логах проскакивает плюс я не запускаю режимы, которые вызывают core в остальном работает как работало в rw

импортируется нормально, без ошибок

Попробовал откатить версию zfs не помогло

у меня оно просто в логах проскакивает плюс я не запускаю режимы, которые вызывают core в остальном работает как работало в rw

Не совсем понял про режимы

Как в итоге вы запускаете пул?

у меня есть виртуалки с федорой и разные контейнеры без них

тк это вызывает паник

тк это вызывает паник

Еще раз, я запутался. Как мне импортнуть пул?

zpool import

У меня нет виртуалок. У меня есть физический сервер

zpool import

Это я уже сделал. Ошибка PANIC

а рекавери перед импортом?

Пока есть проблема. Поскольку я для теста попробовал откатиться на предыдущую версию zfs, но импортнуть не получилось т.к. не было нужных фич. Я вернулся обратно на последнюю версию

Но он щас пишет, что тоже фичи какой-то нет ) Вот зараза

В режиме readonly импортится без проблем

Кстати, вопрос, а в режиме readonly scrub запускать можно?

или это бессмысленно?

@ialebedev Я может пропустил что-то. Если у вас не стоит цель во что бы то ни стало запустить имеющийся пул и разобраться, в чем дело, то раз уже есть бэкап - может стоит создать новый пул и развернуть туда все фс из бэкапа? Разумеется, сначала стоит это без затирания исходного пула попробовать. Может, какую то часть.

Ну бэкап сделан через rsync, а не replicate

Поэтому тут только пересобрать пул

Вероятно завтра этим и займусь)

Ну бэкап сделан через rsync, а не replicate

а повторить при помощи zfs send/recv в другое место? я zxfer пользуюсь, там вся процедура в две команды. но, насколько я помню под linux там надо какие-то пути в скрипте менять. а 20тб потоком относительно быстро должны перелиться, хотя всё от скорости интерфейсов зависит.

а повторить при помощи zfs send/recv в другое место? я zxfer пользуюсь, там вся процедура в две команды. но, насколько я помню под linux там надо какие-то пути в скрипте менять. а 20тб потоком относительно быстро должны перелиться, хотя всё от скорости интерфейсов зависит.

только использовать надстройку sanoid/syncoid

Други, а подскажите какое-нибудь решение как это лучше реализовать. Есть сервер с nfs шарой, на ней хранятся файлы рабочие для общего доступа и некоторые конфигурационные файлы, которые едины для всех клиентов. Клиенты при загрузке монтируют nfs шару и работают. А также через символические ссылки с шары клиенты получают общие файлы настроек. Например у всех клиентов .bashrc есть ни что иное как ссылка на .bashrc лежащий на nfs шаре и мне очень удобно вносить в него правки и они сразу появляются у всех пользователей. Вопрос. А есть ли какое-то решение, при котором можно реализовать то же самое, но без символических ссылок. Т.к. например тот же общий bashrc, который я смогу править и автоматом он будет обновляться у всех клиентов. Но при этом каждый bashrc клиента был ты не ссылкой на общий, а физически отдельным файлом. Собственно зачем мне это нужно? А нужно мне это за тем, что если по каким-либо причинам nfs шара отключена, клиенты не теряли общие настройки, общие глобальные переменные и т.п. потому что сейчас например, если nfs шара отключена, то у всех клиентов bashrc фактически становится пустой.

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