LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

2

Как то давно поставил zfs, экспериментируя раздал точки монтирования подтомам. Сейчас решил сменить точку монтирования тома.
Попытка сменить точку монтирования у тома даёт: Dataset is busy
Ладно, сделал set mountpoint=none всем подтомам, сменил точку монтирования тома, а в нём пусто... Сменил у всех подтомов точку монтирования на legacy = получил тот же хрен...
Экспортировал, импортировал том - подтома всё так же «оторваны»

T3T1Solo 706G 92.7G 99.9G /zfs/T3T1Solo
T3T1Solo/Backup 563G 92.7G 41K legacy
T3T1Solo/Backup/gzip-9 563G 92.7G 444G legacy
T3T1Solo/Backup/gzip-9/ShortBackup 118G 92.7G 118G legacy
T3T1Solo/Backup/lz4 27K 92.7G 27K legacy
T3T1Solo/Backup/off 24K 92.7G 24K legacy
T3T1Solo/DL 43.2G 92.7G 43.2G legacy
T3T1Solo/subYDZFS 72K 92.7G 24K legacy
T3T1Solo/subYDZFS/Obsolete 24K 92.7G 24K legacy
T3T1Solo/subYDZFS/Solo 24K 92.7G 24K legacy

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

Или сделать брутально? Создать новые подтома и рсинкнуть туда старые?

★★★

Последнее исправление: n0mad (всего исправлений: 6)

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

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

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

Теперь если захочу опять сменить точку монтирования тома - надо будет явно менять все подтома... через предварительный «none» а предстоит всё это разперерсинкнуть между винтами и создать zfs зеркало.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 2)
Ответ на: комментарий от mord0d

zfs inherit -rS mountpoint T3T1Solo/subYDZFS

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

n0mad ★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

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

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

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Ну и если хочется в другое место, то после переноса делается 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). ☺

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

А взять штатные средства 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.

n0mad ★★★
() автор топика
Ответ на: комментарий от mord0d

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

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

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 2)
Ответ на: комментарий от n0mad

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

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

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

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

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

zstd-19 дал жару

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

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

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

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

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

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

(я не знаю ☺).

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

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

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

Больше чем 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 юзать, если же нужно ещё и с приемлемой скоростью, то тут придётся искать компромисс.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от mord0d

zfs inherit -rS mountpoint T3T1Solo/subYDZFS

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

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

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

Да

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

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

Clockwork ★★★★★
()
Ответ на: комментарий от n0mad

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

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?

Верно.

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

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

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

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

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

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

n0mad ★★★
() автор топика