Разобрался с ошибкой импорта по старым TXG 💪.
Сообщение у них не верное.
Дело не в недоступности дейвайса, а в ошибках проверки данных/метаданных при импорте.
Когда отключил
/sys/module/zfs/parameters/spa_load_verify_data
/sys/module/zfs/parameters/spa_load_verify_metadata
- то импорт стал происходить мгновенно (ранее для разных TXG занимал от 50 минут до 2+ часов, прежде чем ошибку unavailable выдавал).
Только это параметры НЕ динамические, нужно их в /etc/modprobe.d/zfs.conf прописывать и перегружаться.
PS Однако основная проблема не решилась: со старыми TXG импортируется также, как с дефолтным и выдает на основную папку с данными ☠️
reading directory '/s15/289/storage/storage': Invalid exchange
PPS Что интересно - та же самая команда БЕЗ опции -T не проверяет данные/метаданные, импортирует сразу (с дефолтным TXG)
PPPS И еще про unavailable.
Для эксперимента пробовал в -T подставлять не только те 32 TXG, которые выдал zdb, но и более ранние (в надежде, что там импортируется валидный эксчейндж).
Немножко думает и выдает ту же самую вводящую в заблуждение ошибку
cannot import 's15': one or more devices is currently unavailable
Free
Free
PPPS И еще про unavailable.
Для эксперимента пробовал в -T подставлять не только те 32 TXG, которые выдал zdb, но и более ранние (в надежде, что там импортируется валидный эксчейндж).
Немножко думает и выдает ту же самую вводящую в заблуждение ошибку
cannot import 's15': one or more devices is currently unavailable
Интересно: сейчас попробовал добавить n к импорту с таким вот более ранним TXG - команда мгновенно отработалась без каких-либо сообщений.
Считает, что такой импорт возможен 😳???
Vladislav
Free
Ну что-то она проверяет.
Например, если пул перенесен с другого хоста без экспорта - говорит, что нужно будет -f использовать.
Ну и сели бы совсем не проверяла - то как тогда
Determines whether a non-importable pool can be made importable again
Хотя вот другие опции (-T с каким-то - может даже невалидным TXG) -n наверное не смотрит. Сваливается сразу в свой стандартный алгоритм проверки
exit_node🙂↕️
параллельно к лимитам dirty write buffers, но их обычно на небольшом потоке записи мало смысла крутить
Какие параметры отвечают за dirty write buffers?
Нужно ли менять что-то кроме параметров zfs_dirty_data_max и zfs_dirty_data_max_percent?
exit_node🙂↕️
Сейчас подтюнил эти параметры, тестирую виртуалки на zvol. Ведут себя так же как при cache=unsafe, за исключением неприятной особенности. В virt-manager виртуалка "зависает" со статусом "Выключается", пока не дозапишутся данные из кэша
Aleksey
Добрый день возможно ли такая практика в zfs, которую я применяю в btrfs : на работающую систему с эталонной системы я подкачиваю новый более свежий RO снапшот @rootfs-new далее я его восстанавливаю в subvol @rootfs-new-rw и назначаю его подтомом по-умолчанию и после перезагрузки система уже загрузится в обновленный @rootfs-new-rw
Roman
Fedor
В новой солярке прикольная фича
https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/retaining-files-on-your-zfs-file-system.html
central
В новой солярке прикольная фича
https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/retaining-files-on-your-zfs-file-system.html
как будто бы это уже не должно быть на уровне файловой системы
Δαρθ
В новой солярке прикольная фича
https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/retaining-files-on-your-zfs-file-system.html
типа теперь фс должна делать find по кронтабу а не юзер/админ? )
Δαρθ
как будто бы это уже не должно быть на уровне файловой системы
вот как мне кажется, делать хард ридонли и неудаляемость фс не должна.
Fedor
По позиксу неудаляемость многие на уровне атрибутов уже умеют, тут больше будто про таймштамп протухания этого флага
Δαρθ
По позиксу неудаляемость многие на уровне атрибутов уже умеют, тут больше будто про таймштамп протухания этого флага
ммм. а что за атрибут такой?
Δαρθ
просто так чтоб не удалить было на диру надо ридонли воткнуть вроде как
Fedor
chattr -i
Fedor
Файл с установленным атрибутом `i' становится полностью не модифицируемым (недосягаемым): он не может быть удален или переименован, никакие ссылки не могут быть созданы на этот файл и никакие данные не могут быть записаны в него. Только суперпользователь или процесс, обладающий возможностью CAP_LINUX_IMMUTABLE может установить или очистить такой атрибут
Artem
Если руту можно, то ладно.
А то вообще дурдом какой-то
George
По позиксу неудаляемость многие на уровне атрибутов уже умеют, тут больше будто про таймштамп протухания этого флага
хехе, выглядит даже дёшево в реализации - просто при создании файла мета выставляется, на попытке удалить - читается и валидируется)
Fedor
Free
Почему при пересылке между пулами (на разных серверах) размер датасета может измениться?
Все параметры исходного и конечного датапула одинаковы.
Различаются только версии zfs - неужели это может иметь значение?
Исходынй датасет
root@S06 ~# zfs list | grep 329
my/329 2.09T 48.2T 2.09T /my/329
my/329@send0 1.42G - 2.09T -
my/329@send1 0B - 2.09T -
root@S06 ~# zfs get recordsize | grep 329
my/329 recordsize 4M inherited from my
root@S06 ~# zfs get compression | grep 329 my/329 compression lz4 inherited from my
root@S06 ~# zfs get compressratio | grep 329
my/329 compressratio 1.38x -
root@S06 ~# zfs version
zfs-2.3.1-1~bpo12+1
zfs-kmod-2.3.1-1~bpo12+1
Конечный датасет
root@S04 ~# zfs list | grep 329
s10/329 2.16T 6.74T 2.16T /s10/329
s10/329@send0 1.06G - 2.16T -
s10/329@send1 0B - 2.16T -
root@S04 ~# zfs get recordsize | grep 329
s10/329 recordsize 4M inherited from s10
root@S04 ~# zfs get compression | grep 329
s10/329 compression lz4 inherited from s10
root@S04 ~# zfs get compressratio | grep 329
s10/329 compressratio 1.39x -
root@S04 ~# zfs version
zfs-2.2.7-1~bpo12+1
zfs-kmod-2.2.7-1~bpo12+1
Пересылка zfs send -Lec...
sexst
Compressratio разный жеж
Free
Там куда пересылаешь обычно может быть больше сжатие,потому что это запись по новой
Пересылка вообще-то с опциями -Lec.
-c, --compressed
Generate a more compact stream by using compressed WRITE records for blocks which are compressed on disk and in memory (see the compression property for details). If the lz4_compress feature is active on the sending system, then the receiving system must have that feature enabled as well.
На обеих сторонах на пуле lz4, передуются сжатые данные
Free
разные ashift, геометрия пула влияют к примеру
ashift у обоих 12.
Геометрия - да, разная: исходный raidz2 из 17 дисков, конечный - single disk.
В этом дело?
Vladislav
Пересылка вообще-то с опциями -Lec.
-c, --compressed
Generate a more compact stream by using compressed WRITE records for blocks which are compressed on disk and in memory (see the compression property for details). If the lz4_compress feature is active on the sending system, then the receiving system must have that feature enabled as well.
На обеих сторонах на пуле lz4, передуются сжатые данные
Иии? Из-за того как у тебя L опция у тебя блоки разжимаются, сжимаются заново и передаются
Vladislav
А не, наоборот
George
ashift у обоих 12.
Геометрия - да, разная: исходный raidz2 из 17 дисков, конечный - single disk.
В этом дело?
так эти пулы тогда очень разные, а не одинаковые, да :))))))))))
у raidz на мелких блоках менее эффективна аллокация
Станислав
Не успел написать, что без неё как раз не работает -с))
George
так эти пулы тогда очень разные, а не одинаковые, да :))))))))))
у raidz на мелких блоках менее эффективна аллокация
точнее сказать - у raidz в зависимости от геометрии минимальный размер аллокации разный, и обычно сильно выше чем ashift
George
ashift у обоих 12.
Геометрия - да, разная: исходный raidz2 из 17 дисков, конечный - single disk.
В этом дело?
только интересно, что наоборот получилось, что на НЕraidz вы видите размер больше
Free
так эти пулы тогда очень разные, а не одинаковые, да :))))))))))
у raidz на мелких блоках менее эффективна аллокация
Ну вот получилось, что на raidz был размер меньше, т.е. как будто наоборот
George
но суть - надо собрать разницу пулов.
А, в 2.3 релизе приехали мои доработки про более умные отсечки при сжатии, на 2.2 некоторые данные могут считаться незжимаемыми раньше чем в новом коде. Но это надо прям прокапывать и на конкретных данных проверять
George
в целом, если гемоетрия и версия кода разная - то скорее нормально, что разница по размерам может быть в процентах
sexst
А мне всё ещё интересно насколько отличается несжатый размер)
Free
А мне всё ещё интересно насколько отличается несжатый размер)
Ну по compressratio 1.39x можно прикинуть.
du запустил для интереса, но долго считать будет: там миллионы файлов
sexst
Ну по compressratio 1.39x можно прикинуть.
du запустил для интереса, но долго считать будет: там миллионы файлов
Прикинуть я могу, мне любопытно различаются ли uncompressed на двух хостах по факту
sexst
А этого я посчитать, очевидно, не могу
sexst
В целом можно и проигнорить, это чисто любопытство
Free
В целом можно и проигнорить, это чисто любопытство
Напишу, как посчитает.
Но погрешность (небольшая) будет: час назад запустил работу с конечным датасетом, немного данные измениться могут. Сейчас остановил.
Vladislav
Zdb?
sexst
Так оно ж в атрибутах пула показывает размер до сжатия вроде, не?
Станислав
Напишу, как посчитает.
Но погрешность (небольшая) будет: час назад запустил работу с конечным датасетом, немного данные измениться могут. Сейчас остановил.
А что показывают logicalreferenced и logicalused?
Free
Совпадают.
Исходный:
NAME PROPERTY VALUE SOURCE
my/329 logicalreferenced 3.00T -
my/329 logicalused 3.00T -
Конечный:
NAME PROPERTY VALUE SOURCE
s10/329 logicalreferenced 3.00T -
s10/329 logicalused 3.00T -
sexst
Совпадают.
Исходный:
NAME PROPERTY VALUE SOURCE
my/329 logicalreferenced 3.00T -
my/329 logicalused 3.00T -
Конечный:
NAME PROPERTY VALUE SOURCE
s10/329 logicalreferenced 3.00T -
s10/329 logicalused 3.00T -
В pretty формате точно не показывает. ЕМНИП, ключ -p покажет в сырых байтах
Free
Исходный
NAME PROPERTY VALUE SOURCE
NAME PROPERTY VALUE SOURCE
my/329 logicalreferenced 3293747142144 -
my/329 logicalused 3295123609600 -
Конечный
NAME PROPERTY VALUE SOURCE
s10/329 logicalreferenced 3293450937344 -
s10/329 logicalused 3296692861952 -
Но, как я говорил, немного конечный датасет уже изменился 🤷♂️
Но разница всего 0.009% - сильно меньше, чем разница сжатых данных.
Сжатые на конечном датасете практически не изменились:
root@S04 ~# zfs list | grep 329 s10/329 2.16T 6.74T 2.16T /s10/329
s10/329@send0 1.06G - 2.16T -
s10/329@send1 302M - 2.16T -
Alter Ego
есть 16 hdd по 500гб, что-то можно из них собрать толковое? подскажите пожалуйста
Evgeny
Пирамидку
Alexey
есть 16 hdd по 500гб, что-то можно из них собрать толковое? подскажите пожалуйста
какие требования к пулу?
Alter Ego
какие требования к пулу?
обычные, никаких космических технологий, пары дисков для на случай смерти, я склонялся к raidz2
Ivan
обычные, никаких космических технологий, пары дисков для на случай смерти, я склонялся к raidz2
тогда лучше raidz20 сделать чтоб скорость не совсем дно была
Alexey
дисков много Вы хотите добавить. Будет либо много полок (кол-во дисков в объединении), либо большая полка. Такие большие массивы не рекомендуют создавать... Хотя можно сделать:
draid3 2 полки по 7 дисков. Итого 14 дисков
draid2 2 полки по 6 дисков. Итого 12.
Alexey
на большом массиве не стоит использовать raidz. У draidz более быстрая синхронизация данных при выходе из строя диска.
Кстати, оставшиеся диски можно использовать под замену.
Georg🎞️🎥
на большом массиве не стоит использовать raidz. У draidz более быстрая синхронизация данных при выходе из строя диска.
Кстати, оставшиеся диски можно использовать под замену.
А вы сами этот дрэдз использовали в проде ? Есть опыт нескольких лет хотя бы ?
Или просто читали, что «хорошая вещь» ?
Alexey
в тестах
Georg🎞️🎥
На каких конфигурациях массивов ?
Alexey
на реальном железе не тестил, в виртуалке, на nvme устройствах.
Georg🎞️🎥
Ну то есть опыта создания пула на 60-100 винтов и теста в работе не было ? Ясно 🤝
Nvme и hdd это же очень близко по принципу работы и скорости :)))
Georg🎞️🎥
Тогда к чему такие «рекомендации» , если толком не делали, интересно 🤔
Alexey
Georg🎞️🎥
И то хорошо 🤝
Vladislav
Vladislav
Это всего 8ТБ RAW
Vladislav
Он про один ведев на 16 винтов скорее
При таких объёмах raidz2 (хотя я бы тоже предложил stripe over raidz2) это не смертельно
Georg🎞️🎥
При таких объёмах raidz2 (хотя я бы тоже предложил stripe over raidz2) это не смертельно
Мы сделали 2 хRaidz3 по 15 винтов в каждом , для архива
Диски по 14tb
Georg🎞️🎥
Потому и три винта на вылет )
Vladislav
Смертельнее в этой схеме скорее тот факт, что это 500ГБ 2.5'' и потенциально ноутбочные WD Blue какой-нибудь
Georg🎞️🎥
Так и есть скорее всего )) может Тошибы из старых мак буков ))
Станислав
Так и есть скорее всего )) может Тошибы из старых мак буков ))
Так на них вам может не хватить 3 дисков резервирования)
Georg🎞️🎥
Так на них вам может не хватить 3 дисков резервирования)
Где - на них ? 100 процентных гарантий никакой рейд не дает, вы же в курсе да ?
Alexey
Мы сделали 2 хRaidz3 по 15 винтов в каждом , для архива
Диски по 14tb
а почему Вы так сделали?
Alexey
а какой объем recordsize и какого объема минимальный файл? средний файл?
Georg🎞️🎥
а какой объем recordsize и какого объема минимальный файл? средний файл?
Миллионы мелких файлов
1m поставили