Все это будет приближенно

именно, ни дедуп ни компрессию невозможно заранее рассчитать. Так что если у вас переподписка по месту больше 1, то такие ситуации возможны

А что с данными и с доступом на запись по итогу будет ? Датасеты такой конфигурации будут разделять общее пространство пула ?

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

резервируя на 100ГБ больше, чем есть на пуле, вы сами создаёте эту ситуацию

можете ещё тут обсудить с коммьюнити при желании https://github.com/openzfs/zfs/discussions

(в общем то, дедуп и сжатие для того и нужны, чтобы смочь запихнуть в пул больше чем там есть :D )

Всем привет. Помогите разобраться с поведением или это баг в zfs. Есть пул на 1000 гигов. На нем я не могу создать 2 толстых файловых системы zfs на 500 и 600 гигов (refreservation = 500 и 600 гигов соответственно). И это правильно. НО 1 создаю толстую ФС на 500 гигов 2 включаю на ней дедупликацию 3 заливаю туда 200гиг, т.е. 20 одинаковых файлов по 10 гигов 4 наблюдаю картину что реально записалось чуть больше 10 гигов на пул и коэф дедупа 20 5 вижу что 190 гигов толстая фс вернула пулу , потому что у пула свойство available увеличилось примерно на столько. 6 создаю вторую толстую фс на 600 гиг, zfs разрешило создать 8 на пуле ещё 90 гиг свободных вижу 9 удаляю все данные с дедуплицированной толстой фс 10 я так понимаю она пытается себе назад 190 вернуть 11 вижу что те 90 свободных из пула исчезли , на пуле стало 0 , но откуда ещё 100 гигов удалось взять ???? 12 результат следующий , что не получилось вначале сделать , удалось другим путём , у меня 2 Толстых фс 500 и 600 гигов соответственно на пуле в 1000 гигов. Вопрос откуда эти 100 гиг если их физически нет. Получается толстые фс которым предоставлено обязательное пространство делят между собой общее пространство пула ? Что будет с данными если забить и ту и ту фс полностью ? Они перетруться или zfs не даст записать ? Как сумма refreservation 2х датасетов больше чем размер пула ???? Можете пожалуйста объяснить такое поведение???

создавалось : zfs create pool1/fs1 zfs set refquota=2.08T pool1/fs1 zfs set refreservation=2.08T pool1/fs1 также пробовалось создавать через функции zfs: zfs_create(...) zfs_prop_set(...)

Но на 9 пункте все удаляется

При удалении я ожидал какой нить ошибки связанной с памятью

почему?

Потому что в какой то момент зарезервированное место стало больше реального на пуле. И обращаясь к ману видно что происходит разногласие между описанием и реальной работой

"пока работает так", если кратко)

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

наверное стоило бы пометить взаимоотношения резервации и дедупликации

А почему в убунте программа «диски» пишет про zfs какуюто дичь?

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

В продолжение о дедупе. Ещё не могли бы пояснить механизм дедупликации в zfs. Правильно ли я понимаю сама дедупликация происходит онлайн (т.е. дедуплицируются новые блоки после включения опции дедупа до ее отключения, старые блоки в режиме офлайн не дедуплицируются) и при этом она асинхронная (т.е. данные сначала записываются на диск, а потом уже происходит дедупликация через сравнение контрольных сумм, и получается что происходит разрастание до реальных размеров, после повторяющиеся блоки чистятся). Так ли все работает и есть ли возможность как то менять асинхронный/синхронный режимы вручную ? Или вручную управлять онлайн/офлайн режимом, кроме как перезаписывать данные способом send/recv?

про дедуп можно еще сторону VDO от redhat посмотреть у VDO накладные расходы на дедуп меньше

Дедуп сейчас строго онлайн синхронный, в момент записи сравнивается хеш, и если уже есть - только в dedup table (ddt) на диске счётчик изменится

В теории я тоже везде такое описание читал. Но вот странно на практике, при тестировании zvol расшаренного по iscsi протоколу заметил что свободное место на пуле уменьшается. Уменьшается практически на тот же размер что мы пишем на клиенте, а после уже начинает обратно освобождаться соизмеримо коэффициенту дедупа. Такое ощущение как будто дедуп происходит асинхронно в параллельном потоке

В теории я тоже везде такое описание читал. Но вот странно на практике, при тестировании zvol расшаренного по iscsi протоколу заметил что свободное место на пуле уменьшается. Уменьшается практически на тот же размер что мы пишем на клиенте, а после уже начинает обратно освобождаться соизмеримо коэффициенту дедупа. Такое ощущение как будто дедуп происходит асинхронно в параллельном потоке

А ты изменял данные или только писал новые в тестах?

В теории я тоже везде такое описание читал. Но вот странно на практике, при тестировании zvol расшаренного по iscsi протоколу заметил что свободное место на пуле уменьшается. Уменьшается практически на тот же размер что мы пишем на клиенте, а после уже начинает обратно освобождаться соизмеримо коэффициенту дедупа. Такое ощущение как будто дедуп происходит асинхронно в параллельном потоке

В теории я тоже везде такое описание читал. Но вот странно на практике, при тестировании zvol расшаренного по iscsi протоколу заметил что свободное место на пуле уменьшается. Уменьшается практически на тот же размер что мы пишем на клиенте, а после уже начинает обратно освобождаться соизмеримо коэффициенту дедупа. Такое ощущение как будто дедуп происходит асинхронно в параллельном потоке

sync; echo 3 > /proc/sys/vm/drop_caches

Видит каждый датасет как отдельный диск?

Прокс создаёт диски в хранилищах. Размер блока это свойство хранилища. Создайте несколько хранилищ с разными размерами блоков и тогда вы сможете создавать диски в каждом из хранилищ и эти диски получат разные размеры блоков. 8к наиболее оптимален для ВМ с тем же постгрессом. Для ВМ общего назначения можно сделать 16к. А лучше всего провести собственные тесты производительности дисков с разными размерами блоков.

Да в жопу зфс на линуксе это убожество кривое

это справедливо только если есть несколько пулов ? или можно в одном пуле разные стораджи делать с разными размерами volblocksize?

Да в жопу зфс на линуксе это убожество кривое

и линукс туда же и комплюктеры эти ваши

Дурак?

чего небезопасного-то?

нет. еще вопросы будут ?