Куда подевалось место на ZFS

Alex Korchmar написал(а) к Vova Uralsky в Nov 17 09:41:19 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Vova Uralsky <Vova.Uralsky@f257.n5030.z2.fidonet.org> wrote:

VU> Ещё раз и по буквам. Резерв на датасете состоит из блоков, принадлежащих
ты бредишь, резерв на датасете состоит из битиков, записанных в поле
"reservation". Никакого "списка блоков, принадлежащих датасету" не существует,
пока в них что-то не попытаются записать.

VU> Вот я и пытаюсь выяснить, действительно ли это всё ещё актуально?
VU> А ты, вот, не хочешь (4) проверять. Может починили уже давно?
где соответствующий комит, где громкие вопли и танцы "мы чинили-чинили, и
починили!" ? Ась, нету? Значит, и проверять нечего и незачем - в лучшем случае,
окажется что да, починили - сами этого не заметив, случайно, в ходе каких-то
улучшизмов слегка изменив последовательность операций. Завтра точно так же,
не заметив, сломают обратно.
В худшем ты облажаешься, поставив эксперимент неверно.

Лишнего пула на, хотя бы, 4T, где проблема уже актуальна, случись что, и где
видна глазом разница в скорости доступа, у меня лично нет. (но ты всегда можешь
проспонсировать исследования, разумеется - я с радостью забью еще 4 тера
порнухой за твой счет)


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Vova Uralsky в Nov 17 18:02:48 по местному времени:

06 нояб. 2017, понедельник, в 20:20 NOVT, Vova Uralsky написал(а):

VU> Ещё раз и по буквам. Резерв на датасете состоит из блоков, принадлежащих
VU> датасету.

Это прямо противоречит и документации, и продемонстрированному поведению.
И из того, и из другого следует, что резерв не принадлежит датасету.

VU> Они не являются свободными, хотя в них не записано никаких данных.

Да нет этих "блоков" вообще, это просто лимит.

VU> Они не доступны другому датасету.

Да - занять свободные блоки пользовательскими данными в нарушение резервирования,
действительно, нельзя, но, как показал тест, их может использовать сама ZFS
на свои внутренние нужды - в частности, чтобы отработал rm - а этого мы и добиваемся.

VU>>>>> К тому же мы ещё не проверили, работает ли оно действительно так,
VU>>>>> как ты предполагаешь.
EG>>>> # zfs get reservation
EG>>>> NAME PROPERTY VALUE SOURCE
EG>>>> md0 reservation 100M local
VU>>>> ---------------------^^^^

EG>>>> md0 3,97G 3,84G 128M - 47% 96% 1.00x ONLINE -
VU>>>> ---------------------^^^^

VU> <sarcasm>
VU> Магический пул: резервируем 100M, заполняем до конца, сколько осталось
VU> незаполнено? Првыильно, 128M.

А откуда следует, что ZFS не может для своих нужд ещё дополнительно
резервировать место "неявно"? Да ниоткуда.

VU> Ты что-то недокопипэйстил? Или действительно считаешь что 100M == 128M?

Я считаю, что 100M <= 128M, а только это и требуется.

VU>>> А вопросы были такие:
VU>>> 1. Если заполнить датасет на 100%, можно ли удалить в нём файл? (если
VU>>> он зажат квотой, мы знаем, можно, а если резервированием на другом
VU>>> датасете?)
EG>> Да, именно это я продемонстрировал.
VU> Не вижу. plausibility check failed

Датасет был заполнен на 100%. Пул - нет. Sapienti sat.

VU> Жаль что Korchmar effect нам никто не хочет продемонстрировать.

Так путь он и демонстрирует, ну или тот, кому он интересен, этот эффект.
Я его не наблюдал и мне он вообще неинтересен. Мне интересно ровно
обратное - как получить гарантию его невоспроизведения практически
удобным способом.

Eugene
--
Enter old password: xxx
Enter new password: yyy
Confirm password: подтверждаю
--- slrn/1.0.2 (FreeBSD)

Vova Uralsky написал(а) к Eugene Grosbein в Nov 17 20:14:14 по местному времени:

Нello Eugene!

07 Nov 17 18:02, Eugene Grosbein wrote to Vova Uralsky:

VU>> Ещё раз и по буквам. Резерв на датасете состоит из блоков,
VU>> принадлежащих датасету.
EG> Это прямо противоречит и документации, и продемонстрированному
EG> поведению.

Ну-ну. Если место зарезервировано для одного датасета, попробуй занять его другим. Успехов. И деже если это тебе просто файлик удалить. Не волнует. Резерв, он железный.

EG> И из того, и из другого следует, что резерв не принадлежит датасету.

ой

VU>> Они не являются свободными, хотя в них не записано никаких данных.
EG> Да нет этих "блоков" вообще, это просто лимит.

Разница?

VU>> Они не доступны другому датасету.
EG> Да - занять свободные блоки пользовательскими данными в нарушение
EG> резервирования,
EG> действительно, нельзя, но, как показал тест, их может использовать
EG> сама ZFS
EG> на свои внутренние нужды - в частности, чтобы отработал rm - а этого
EG> мы и добиваемся.

Х3 :-D

VU>>>>>> К тому же мы ещё не проверили, работает ли оно действительно так,
VU>>>>>> как ты предполагаешь.
EG>>>>> # zfs get reservation
EG>>>>> NAME PROPERTY VALUE SOURCE
EG>>>>> md0 reservation 100M local
VU>>>>> ---------------------^^^^

EG>>>>> md0 3,97G 3,84G 128M - 47% 96% 1.00x ONLINE
EG>>>>> -
VU>>>>> ---------------------^^^^

VU>> <sarcasm>
VU>> Магический пул: резервируем 100M, заполняем до конца, сколько
VU>> осталось незаполнено? Првыильно, 128M.
EG> А откуда следует, что ZFS не может для своих нужд ещё дополнительно
EG> резервировать место "неявно"? Да ниоткуда.

df -h бы хватило, а так, догадки, предположения...

VU>> Ты что-то недокопипэйстил? Или действительно считаешь что 100M ==
VU>> 128M?
EG> Я считаю, что 100M <= 128M, а только это и требуется.

Ну-ну

VU>>>> А вопросы были такие:
VU>>>> 1. Если заполнить датасет на 100%, можно ли удалить в нём файл?
VU>>>> (если он зажат квотой, мы знаем, можно, а если резервированием на
VU>>>> другом датасете?)
EG>>> Да, именно это я продемонстрировал.
VU>> Не вижу. plausibility check failed
EG> Датасет был заполнен на 100%. Пул - нет. Sapienti sat.

Не верю (c)

VU>> Жаль что Korchmar effect нам никто не хочет продемонстрировать.
EG> Так путь он и демонстрирует, ну или тот, кому он интересен, этот
EG> эффект.

:-D

Regards,
Vova

--- Msged/BSD 6.2.0

Vova Uralsky написал(а) к Vova Uralsky в Nov 17 17:58:18 по местному времени:

Нello Vova!

02 Nov 17 20:17, Vova Uralsky wrote to Eugene Grosbein:

VU> фишку надо проверить на фребзде на предмет актуальности.

Проверил на 11.1, работает также как на открытом индейце. В пуле резервируется 4%. (Гросбайн, ты прав, только показать это не смог) Файлы удаляются, ничего резервировать не надо. Когда это изменилось? X3... Как это настраивается, пока не нашёл, если это вообще настраивается.

[root@fbsdx /tank/hlam]# zpool list -v
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP НEALTН ALTROOT
tank 19.9G 19.3G 636M - 62% 96% 1.00x ONLINE -
ada2 19.9G 19.3G 636M - 62% 96%
[root@fbsdx /tank/hlam]# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 19.3G 0 19K /tank
tank/hlam 19.3G 0 19.3G /tank/hlam
tank/reserv 19K 0 19K /tank/reserv
[root@fbsdx /tank/hlam]# df -h .
Filesystem Size Used Avail Capacity Mounted on
tank/hlam 19G 19G 0B 100% /tank/hlam

Попробовал на 100G пуле в виртуалке воспроизвести Korchmar effect. Поскольку стандартные бенчилки очень расстраиваются когда место кончается, а смысл именно в этом, пускал в разных вариантах примерно такое:

while dd if=/dev/zero of=/tank/hlam/$(date +%Н%M%S) bs=$((1024*1024)) count=100
do
:
done
find /tank/hlam | head -1 | xargs rm
find /tank/hlam | while read i
do
dd if=/dev/zero of=$i bs=$((1024*1024)) count=101
done
find /tank/hlam | xargs rm

Время записи примерно 1 секунда, без видимых затыков, то есть их было на весь тест ровно 17 3.4-7.3 секунды. Думаю, мне не удалось воспроизвести. Причины могут быть всякие...

Regards,
Vova

--- Msged/BSD 6.2.0

Alex Korchmar написал(а) к Vova Uralsky в Nov 17 13:32:11 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Vova Uralsky <Vova.Uralsky@f257.n5030.z2.fidonet.org> wrote:

VU> Попробовал на 100G пуле в виртуалке воспроизвести Korchmar effect.
Ко мне этот эффект не имеет ни малейшего отношения - я его никогда своими
глазами не видел, потому что умею читать - до того, как лезть внедрять у
себя незнакомые технологии.

Из здешних последним отметился этими граблями, помнится, Судаков - уже
тогда вызвав этим некоторое удивление, поскольку топтаться по ним было
уже немодно.
Заметим, что никаких 100% у него не было - у него было <90.
Вполне хватило чтобы все стало раком.


> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Nov 17 18:08:24 по местному времени:

Dear Alex,

13 Nov 17 13:32, Alex Korchmar wrote to Vova Uralsky:
VU>> Попробовал на 100G пуле в виртуалке воспроизвести Korchmar effect.
AK> Ко мне этот эффект не имеет ни малейшего отношения - я его никогда
AK> своими глазами не видел, потому что умею читать - до того, как лезть
AK> внедрять у себя незнакомые технологии.

AK> Из здешних последним отметился этими граблями, помнится, Судаков - уже
AK> тогда вызвав этим некоторое удивление, поскольку топтаться по ним
AK> было уже немодно. Заметим, что никаких 100% у него не было - у него
AK> было <90. Вполне хватило чтобы все стало раком.

Справедливости ради должен отметить, что фатального тогда ничего не произошло, пул в негодность не пришёл, оно потихоньку рассосалось.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Alex Korchmar написал(а) к Victor Sudakov в Nov 17 16:38:19 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Справедливости ради должен отметить, что фатального тогда ничего
VS> не произошло, пул в негодность не пришёл, оно потихоньку
ну так ты вовремя успел - или, скорее, первая грабля помешала тебе быстро
добежать до второй, поскольку скорость упала - в том числе и новой записи.

> Alex

--- ifmail v.2.15dev5.4

Vova Uralsky написал(а) к Victor Sudakov в Nov 17 11:29:44 по местному времени:

Нello Victor!

16 Nov 17 18:08, Victor Sudakov wrote to Alex Korchmar:

VS> Справедливости ради должен отметить, что фатального тогда ничего не
VS> произошло, пул в негодность не пришёл, оно потихоньку рассосалось.

Как я уже писал, "Про ZFS рассказывают страшные вещи".

Regards,
Vova

--- Msged/BSD 6.2.0

Victor Sudakov написал(а) к Vova Uralsky в Nov 17 20:45:38 по местному времени:

Dear Vova,

19 Nov 17 11:29, you wrote to me:

VS>> Справедливости ради должен отметить, что фатального тогда ничего
VS>> не произошло, пул в негодность не пришёл, оно потихоньку
VS>> рассосалось.

VU> Как я уже писал, "Про ZFS рассказывают страшные вещи".

А расскажи вместо страшной полезную вещь, как проверить результат работы "zfs send -R zroot@backup > backup.zfs" без реального разворачивания backup.zfs, по аналогии с "restore -rN". Места и времени на это обычно нет.

Пробовал с разными ключами "zfs receive -vnFd foo < backup.zfs" - конец один, типа такого:

cannot receive incremental stream: destination 'foo/ROOT/default' does not exist.

Ну типа да, не существует, а "-d" тебе на что? Или оно в сочетании с "-n" не считается?

Короче, как?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Vova Uralsky в Nov 17 21:49:12 по местному времени:

Dear Vova,

19 Nov 17 11:29, you wrote to me:

VS>> Справедливости ради должен отметить, что фатального тогда ничего
VS>> не произошло, пул в негодность не пришёл, оно потихоньку
VS>> рассосалось.

VU> Как я уже писал, "Про ZFS рассказывают страшные вещи".

А расскажи вместо страшной полезную вещь, как проверить результат работы "zfs send -R zroot@backup > backup.zfs" без реального разворачивания рекурсивного снапшота backup.zfs, по аналогии с "restore -rN". Места и времени на это обычно нет.

Пробовал с разными ключами "zfs receive -vnFd foo < backup.zfs" - конец один, типа такого:

cannot receive incremental stream: destination 'foo/ROOT/default' does not exist.
или
cannot receive: local origin for clone foo/ROOT/install@2017-11-19 does not exist

Короче, как? Задача - проверить читаемость и целостность дампа. У меня вообще сомнения, что после таких ошибок оно развернется в реальной ситуации.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322