zfs - Как очистить mountpoints подтомов? (Привести к изначальному состоянию)

Я конечно сейчас явно пропишу все вложенные туда куда смонтировал T3T1Solo, но правильно ли это?

Увы, иерархия типа есть но попытка сменить точку монтирования тома говорит:

cannot unmount '/zfs/T3T1Solo': pool or dataset is busy 

zfs inherit -rS mountpoint T3T1Solo/subYDZFS

СПАСИБО, о гуру! Казалось бы всё так просто... Если знать.
А то я тут нараскосячил zfs на 3 винтах, никак не соберу воедино зеркало и соло бэкап избранного с этого зеркала. 11T Это жуть как много... рсинк трудится часами...
И всё время вспоминаю анекдот про: «i like to move-it move-it»

рсинк трудится часами

А взять штатные средства ZFS не судбьа?

zfs snap pool1/some/dataset@move-it
zfs send -Lec zfs pool1/some/dataset@move-it | zfs recv -du pool2
zfs destroy pool2/some/dataset@move-it

Кто ж про них читает?

Нафига козе баян, если есть аккордеон, да? (%

Только, наверное zfs destroy pool1/some/dataset@move-it

Нет, я всё правильно написал. ☺

send|recv переносит снапшоты, и потом оно разрастётся из-за CoW как не в себя, если забыть. А на src можно после переноса сам датасет удалить, но раз он собирается разваливать пул, чтобы пересобрать в новый, то это не имеет смысла.

Ну и если хочется в другое место, то после переноса делается zfs rename pool2/some/dataset pool2/shit. Опционально можно потом zfs destroy pool2/some, если не нужен для чего-то другого.

А ещё лучше, если нужно рекурсивно, то:

zfs snap -r pool1/some/dataset@move-it
zfs send -LeRp pool1/some/dataset@move-it | zfs recv -du pool2
zfs list -rH -t snapshot -o name pool2 | grep '@move-it$' | xargs -L1 zfs destroy

Я так вчера одну виртуалку с одного виртуального диска на другой пересаживал (патамушта volblocksize). ☺

А взять штатные средства ZFS не судбьа?

Спасибо, буду иметь ввиду, но я как раз хочу избавиться от лишних датасетов, у меня в #zfs list их такая тьма... Я брал датасет и рсинкал на подтома с разными алгоритмами паковки. Засекал время рсинка и результирующий датасет.

Получил: https://docs.google.com/spreadsheets/d/18MvZioUNdZjNeiHh5yRQg9ikTnQqNwOHFZPyW...

и решил что лучший это zstd, он пакует
64G в 38G за 0:53:53
на Микро ПК, тогда как lz4 пакует
64G в 41.5G за 00:53:06
Разница на моём датасете в -3.5Gb за +47 секунд.

zstd-19 дал жару,
64G в 37.0G за 11:11:24 (ОДИННАДЦАТЬ ЧАСОВ!)

В общем в табличке всё видно, и вся эта иерархия подтомов теперь в моём #zfs list

Всё хочу модифицировать датасет чтобы прогнать весь цикл на SSD.

Я так вчера одну виртуалку с одного виртуального диска на другой пересаживал (патамушта volblocksize). ☺

Спасибо за заклинания, буду вкуривать. У меня это не просто, в связи с последствиями после «ЧМТ несовместимой с жизнью», как написали в первой больнице куда меня доставили, и недели мозговой комы в другой больнице.

я как раз хочу избавиться от лишних датасетов

Ну в уже существующий через send|recv не отправить, да, придётся лапками перетаскивать.

и решил что лучший это zstd, он пакует 64G в 38G за 0:53:53

Так он и по процессору нагрузку больше создаёт.

Ну и zstd это zstd-3. Так в ZFS по умолчанию. Можно и повеселее жать, но дольше и камушком жевать посильнее.

zstd-19 дал жару

Ещё бы! Вообще, zstd-3 и zstd-6 вполне вменяемые опции, больше только если ты действительно знаешь что делаешь (я не знаю ☺).

Так он и по процессору нагрузку больше создаёт.

Больше чем что?
Логично что есть какая то задача, и на zstd эта задача выполняется на 1% дольше чем на lz4 а упаковывает на 10% сильнее, т.е. Процессора используется на 1% больше, а производительность на 10% больше. (Ну это я так, практически «от балды» посчитал).

А тот же gzip-9 эту же инфу ужал ещё на 0.7% больше, но затратил в 3 раза больше времени.

По моей математике, zstd - самый эффективный из представленных алгоритмов.

(я не знаю ☺).

Я искал самый эффективный алгоритм сжатия.

Часть данных сейчас уже в zfs/gzip-9 и при очередном рсинке я их перемещу в zstd.

И кстати рсинк без упаковки, шел даже дольше - 59 минут, практически на 10% дольше.
(Впрочем все замеры есть по ссылке выше)

Больше чем что?

Больше чем lz4, очевидно. И нагрузка у zstd имеет экспоненциальное соотношение к степени сжатия.

Логично что есть какая то задача, и на zstd эта задача выполняется на 1% дольше чем на lz4 а упаковывает на 10% сильнее, т.е. Процессора используется на 1% больше, а производительность на 10% больше. (Ну это я так, практически «от балды» посчитал).

У меня есть датасеты, где используется zstd-6 и дедупликация. Это немножко больно, но у меня мало диска и много процессора. (=

А тот же gzip-9 эту же инфу ужал ещё на 0.7% больше, но затратил в 3 раза больше времени.

gzip никогда не пытался в скорость, он всегда был в эффективность сжатия.

По моей математике, zstd - самый эффективный из представленных алгоритмов.

Я тоже как-то замеры проводил, и тоже остановился на zstd (zstd-3, zstd-6 по ситуации). ☺ Но не повсеместно, а только там, где данных много и они сжимаются. На всём остальном используется lz4.

Я искал самый эффективный алгоритм сжатия.

Если тебе норм заливать 100G со скоростью DSL-модема, то можешь хоть gzip-9 юзать, если же нужно ещё и с приемлемой скоростью, то тут придётся искать компромисс.

Если тебе норм заливать 100G со скоростью DSL-модема, то можешь хоть gzip-9 юзать, если же нужно ещё и с приемлемой скоростью, то тут придётся искать компромисс.

Спасибо за акцент, в следующем подходе к измерениям - буду замерять и скорости чтения скопированного датасета.

zfs inherit -rS mountpoint T3T1Solo/subYDZFS

Уважаемый гуру, я немного прооффтоплю.
Может Вы знаете как правильно поменять режим компрессии для подтома?
Вот скажем есть у меня подтом, там установлено lz4, но я решил сделать его zstd. Как это сделать правильно?
И дополнительный вопрос: Есть ли варианты принудительной перепаковки? Сейчас я просто изменил Compression с lz4 на zstd.
Я так понимаю теперь старые файлы так и останутся lz4 а новые будут писаться в zstd? Можно ли теперь привести к общему знаменателю?

Я так понимаю теперь старые файлы так и останутся lz4 а новые будут писаться в zstd?

Да

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

Пересоздать датасет с нужными свойствами

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

zfs set compression=zstd zpool/dataset
cp -a /zpool/dataset/dir1 /zpool/dataset/dir2
rm /zpool/dataset/dir1
mv /zpool/dataset/dir2 /zpool/dataset/dir1

Больше никак. Компрессия применяется только к новым файлам (поэтому просто mv ничего не даст, inodes останутся теми же, изменится только их metadata).

Я так понимаю теперь старые файлы так и останутся lz4 а новые будут писаться в zstd?

Верно.

Можно ли теперь привести к общему знаменателю?

Скопировать их куда-нибудь и снова скопировать обратно. Но можно прям на месте копировать в новое место, это будут уже новые данные и они пожмутся новым сжатием, а старые затем можно удалить.

Можно ли теперь привести к общему знаменателю?

Скопировать их куда-нибудь и снова скопировать обратно. Но можно прям на месте копировать в новое место, это будут уже новые данные и они пожмутся новым сжатием, а старые затем можно удалить.

Спасибо, ситуация ясна.

Подниму топик.

Как тут и предлагали, пошел через zfs send|zfs receive

Скопировал рекурсивно, но точки монтирования источника и приёмника - стали одинаковыми. Сначала не смог экспортировать приёмный винт и испугался, потом экспортировал. Но другом компе, при импорте - оно смонтировалось в те же каталоги:

T4T3S/:1T 24K 363G 24K /zfs/=Safe/:1T

Делаю: #zfs inherit -rS mountpoint T4T3S/:1T Точка монтирования такой же и остаётся.

Делаю: #zfs set mountpoint=/zfs/=T4T3S/:1T T4T3S/:1T
Получаю:
T4T3S/:1T 24K 363G 24K /zfs/=T4T3S/
:1T

То что и было нужно, ибо сам T4T3S - монтируется в /zfs/=T4T3S

Подумал что косяк может быть в ":"
#zfs rename T4T3S/:1T T4T3S/1T
#zfs inherit -rS mountpoint T4T3S/1T
Точка монтирования как была /zfs/=T4T3S/:1T - так и осталась.
ЧЯДНТ?

Становится всё чудесатее и чудесатее.
Нашел косяк. У меня точка монтирования для тома приехала с тома Safe. Изменил точку монтирования на /zfs/=T4T3S
Часть ресурсов переехала нормально, а с частью ошибки. К сожалению команда ошибок не возвращает, а в журнале ошибок - они появляются:

# zfs get mountpoint T4T3S
NAME   PROPERTY    VALUE        SOURCE
T4T3S  mountpoint  /zfs/=T4T3S  local

# zfs get mountpoint T4T3S/:SB
NAME       PROPERTY    VALUE       SOURCE
T4T3S/:SB  mountpoint  /#SB        received

# zfs inherit -rS mountpoint T4T3S/:SB
# zfs get mountpoint T4T3S/:SB
NAME       PROPERTY    VALUE       SOURCE
T4T3S/:SB  mountpoint  /#SB        received

мар 30 03:15:10 LM79 systemd[1]: \x23SB.mount: Deactivated successfully.

и ничего не происходит.

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

Импортировать нужно с ключом -R (zpool import -R /mnt ...), чтобы такого не происходило. Тогда оно смонтирует всё автомонтируемое относительно ALTROOT, а не сразу в корень.

Делаю: #zfs inherit -rS mountpoint T4T3S/:1T Точка монтирования такой же и остаётся.

inherit делает сброс в умолчание, а так как у тебя значение и так было по умолчанию, оно ничего не сделало фактически.

Точка монтирования как была /zfs/=T4T3S/:1T - так и осталась.
ЧЯДНТ?

Имя датасета и точка монтирования не обязательно должны совпадать. Точка монтирования наследуется из имени только в момент создания датасета, во всех остальных случаях её нужно менять вручную.

Спасибо за помощь, и прости за то что я так туп :(

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

Импортировать нужно с ключом -R (zpool import -R /mnt ...), чтобы такого не происходило. Тогда оно смонтирует всё автомонтируемое относительно ALTROOT, а не сразу в корень.

Спасибо за совет. Хотел применить, но сначала надо экспортировать:

# zpool export T4T3S
cannot export 'T4T3S': pool is busy

# zfs list|grep T4T3S
T4T3S                                       3.17T   363G       30K  /zfs/=T4T3S
T4T3S/:1T                                     24K   363G       24K  /zfs/=T4T3S/:1T
T4T3S/:Backup                                 24K   363G       24K  /zfs/=T4T3S/:Backup
T4T3S/:Dedup                                14.5G   363G     14.5G  /zfs/=T4T3S/:Dedup
T4T3S/:Media                                1.54T   363G     1.54T  /zfs/=T4T3S/:Media
T4T3S/:SB                                   10.0G   363G     10.0G  /#SB
T4T3S/:cry                                   108G   363G      108G  /opt/:cry
T4T3S/:ecry                                 84.5G   363G     84.5G  /opt/:ecry
T4T3S/:encfs                                  24K   363G       24K  /zfs/=T4T3S/:encfs
T4T3S/:ext                                    24K   363G       24K  /zfs/=T4T3S/:ext
T4T3S/:pub                                  1.42T   363G     1.42T  /opt/:pub

Делаю: #zfs inherit -rS mountpoint T4T3S/:1T Точка монтирования такой же и остаётся.

inherit делает сброс в умолчание, а так как у тебя значение и так было по умолчанию, оно ничего не сделало фактически.

Тем не менее я уже сделал #zfs set mountpoint=/zfs/=T4T3S T4T3S
потом опять: #zfs inherit -rS mountpoint T4T3S/:SB

#zfs list
...
T4T3S/:SB                                   10.0G   363G     10.0G  /#SB
...

Точка монтирования как была /zfs/=T4T3S/:1T - так и осталась.
ЧЯДНТ?

Имя датасета и точка монтирования не обязательно должны совпадать. Точка монтирования наследуется из имени только в момент создания датасета, во всех остальных случаях её нужно менять вручную.

Так в прошлом топике как раз у меня и был вопрос - как весь этот зоопарк привести к одному корню? Есть же T4T3S/... Пумсть он и ложится туда.

Конечно руки чешутся - тупо ручками перезадать, но тогда будет разрушен этот косчяк - котоорый хочется привести в порядок методами типа «inherit»

Вышел из X, зашел в консоль, экспорт прошел.

zpool import - вложил всё в себя, чуть ли не рекурсивно :(
Всё таки ручками править....
Обидно что не сработал zfs inherit
От zpool import -R - получил матрёшку:

T4T3S                                       3.17T   363G       30K  /zfs/=T4T3S/zfs/=T4T3S
T4T3S/:1T                                     24K   363G       24K  /zfs/=T4T3S/zfs/=T4T3S/:1T
T4T3S/:Backup                                 24K   363G       24K  /zfs/=T4T3S/zfs/=T4T3S/:Backup
T4T3S/:Dedup                                14.5G   363G     14.5G  /zfs/=T4T3S/zfs/=T4T3S/:Dedup
T4T3S/:Media                                1.54T   363G     1.54T  /zfs/=T4T3S/zfs/=T4T3S/:Media
T4T3S/:SB                                   10.0G   363G     10.0G  /zfs/=T4T3S/#SB
T4T3S/:cry                                   108G   363G      108G  /zfs/=T4T3S/opt/:cry
T4T3S/:ecry                                 84.5G   363G     84.5G  /zfs/=T4T3S/opt/:ecry
T4T3S/:encfs                                  24K   363G       24K  /zfs/=T4T3S/zfs/=T4T3S/:encfs
T4T3S/:ext                                    24K   363G       24K  /zfs/=T4T3S/zfs/=T4T3S/:ext
T4T3S/:pub                                  1.42T   363G     1.42T  /zfs/=T4T3S/opt/:pub

Зачем тебе все эти = и : в именах и путях?

#SB

И да, помимо того, что @ зарезервировано для снапшотов, # зарезервировано для букмарков (man zfs-bookmark), потому и этот символ в именах использовать не получится.

Я до сих пор не понимаю зачем ты создаёшь себе сложности. (=

Или может можно парой команд привести это к нормальному виду?

Скриптом. (=

Зачем тебе все эти = и : в именах и путях?

В соседнем топике писал, память отбил... ":" Это чистый подтом, а «=» Это точка монтирования подтома вне иерархиии тома.

#SB

И да, помимо того, что @ зарезервировано для снапшотов, # зарезервировано для букмарков (man zfs-bookmark), потому и этот символ в именах использовать не получится.

Спасибо за акцент, но тут это не в имени, а точка монтирования. Вполне взлетает.

Я до сих пор не понимаю зачем ты создаёшь себе сложности. (=

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

Или может можно парой команд привести это к нормальному виду?

Скриптом. (=

Ну, после темы с «inherit» я надеялся что можно как то привести к изначальному состоянию, как после создания подтома.
Ну если нет, тогда ручками... (в скрипте). Это не сложно, жаль что чуда не случилось и создатели не предусмотрели такую возможность (Сброса к первоначальному состоянию).
Спасибо за помощь! Теперь наверняка не раз вернусь к этому топику, пока наконец не запомню.

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

Главное что ты не сдался. Остальное приложится со временем.

после темы с «inherit» я надеялся что можно как то привести к изначальному состоянию

Некоторые параметры наследуются, но только при создании датасета. Изменение родительского параметра почти никогда не наследуется уже существующими дочерними.
Почитай man zfsprops.

жаль что чуда не случилось и создатели не предусмотрели такую возможность

Отсутствие такой возможности в принципе логично (по крайней мере в контексте точек монтирования):
Допустим, у тебя есть датасет zpool/something/logs, который монтируется в /var/log, а сам zpool/something может как не иметь точки монтирования вовсе (mountpoint=none), так и быть смонтирован как какая-нибудь файлопомойка, которую ты можешь монтировать куда-нибудь в /opt, а потом передумать и смонтировать в /media, при этом не отломав себе дочерний датасет с логами.

Сброса к первоначальному состоянию

Технически у пропа mountpoint нет дефолтного значения (не смотря на то, что при создании пула точка монтирования корневому датасету присваивается от его имени в корне системы или ALTROOT, если при создании не указано иного), и наследуется оно только при создании дочерних датасетов.