= Сообщение: 6173 из 10756 ===================================== RU.UNIX.BSD =
От : Vova Uralsky 2:5030/257 06 Nov 17 19:20:14
Кому : Eugene Grosbein 06 Nov 17 19:20:14
Тема : Re: Куда подевалось место на ZFS
FGHI : area://RU.UNIX.BSD?msgid=2:5030/257+5a00bd11
На : area://RU.UNIX.BSD?msgid=grosbein.net+c74b43bd
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=grosbein.net+a535d010
==============================================================================
Hello Eugene!
06 Nov 17 14:44, Eugene Grosbein wrote to Vova Uralsky:
VU>>>> Ты соскочил с темы. Место надо не только для удаления, а просто для
VU>>>> работы. То есть нужны блоки, не принадлежащие никакому датасету.
VU>>>> Резервирование блокирует незанятые блоки, ухудшая ситуацию в
VU>>>> переполненном пуле.
EG>>> Оно блокирует незанятые блоки для дела.
VU>> Это что за "дело" за такое?
EG> "Дело" в данном случае состоит в том, чтобы не допустить заполнения
EG> пула
EG> на 100% никаким датасетом с тем, чтобы при заполнении любого из
EG> датасетов
EG> пула на 100% на самом датасете были бы свободные блоки для того,
EG> чтобы rm с заполненного датасета отрабатывал.
Ещё раз и по буквам. Резерв на датасете состоит из блоков, принадлежащих датасету. Они не являются свободными, хотя в них не записано никаких данных. Они не доступны другому датасету.
VU>> Запись идёт в датасеты, если тебе надо писать не в
VU>> тот датасет, где у тебя резерв, и в пуле места больше нет, то тебе
VU>> просто не повезло.
EG> Вся суть в том, чтобы не допустить события "в пуле места больше нет".
См выше.
VU>>>> К тому же мы ещё не проверили, работает ли оно действительно так,
VU>>>> как ты предполагаешь.
EG>>> # zfs get reservation
EG>>> NAME PROPERTY VALUE SOURCE
EG>>> md0 reservation 100M local
VU>>> ---------------------^^^^
============================^^^^==================
EG>>> md0/fs reservation none default
EG>>> Заполним fs данными из /dev/urandom:
EG>>> # ls -lh /md0/fs
EG>>> total 8059579
EG>>> -rw-r--r-- 1 root wheel 3,8G 5 нояб. 22:46 file
EG>>> # zpool list md0
EG>>> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH
EG>>> ALTROOT
EG>>> md0 3,97G 3,84G 128M - 47% 96% 1.00x ONLINE -
VU>>> ---------------------^^^^
============================^^^^==================
EG>>> # cp file file2
EG>>> cp: file2: No space left on device
EG>>> # rm file
EG>>> rm отработал за доли секунды.
VU>> жаль что ты не смог заполнить md0/fs на 100%,
EG> Почему не смог-то? Смог, и cp это подтвердил лишний раз.
EG> Free 128M относится к пулу, а не к md0/fs.
<sarcasm>
Магический пул: резервируем 100M, заполняем до конца, сколько осталось незаполнено? Првыильно, 128M.
VU>> интересно было бы посмотреть, обломится ли после этого rm?
EG> Hе обломился же :-)
О. да! С чего бы?
VU>> Если у тебя в пуле осталось 128M свободно, что-то
VU>> явно не так.
EG> Всё так, именно это и было целью создания резерва.
Так и создал бы резерв на 128М?
</sarcasm>
VU>> Чтобы заполнть остаток места, не высчитывая свободные байтики, можно
VU>> воспользоваться dd if=/dev/zero of=/md0/fs/fileX. Если ты не включал
VU>> дедупликацию или компрессию, /dev/zero вполне хватит.
EG> Так и заполнял, только из /dev/urandom. Дедупа/компрессии не было,
EG> все опции создания же показывал.
Ты что-то недокопипэйстил? Или действительно считаешь что 100M == 128M?
EG>>> md0 3,97G 1,80M 3,97G - 3% 0% 1.00x ONLINE -
EG>>> Сойдет?
VU>> Я, видимо, не понял цели твоей лабы. Доказать что можно писать в
VU>> dataset почти до конца не отвечает ни на один из поставленных
VU>> вопросов. (мы, вроде, жуём это уже несколько дней)
EG> Цель была продемонстировать, что резервирование на одном из датасетов
EG> пула гарантирует незаполняемость его до отказа и как следствие,
EG> возможность почистить заполненные до отказа датасеты.
Hе сложилось. А жаль.
VU>> А вопросы были такие:
VU>> 1. Если заполнить датасет на 100%, можно ли удалить в нём файл? (если
VU>> он зажат квотой, мы знаем, можно, а если резервированием на другом
VU>> датасете?)
EG> Да, именно это я продемонстрировал.
Hе вижу. plausibility check failed
VU>> 2. Если не (1), можно ли уменьшить резервирование на другом датасете
VU>> и удалить файл из (1)?
VU>> 3. Если убрать резервирование совсем -- заполнение пула на 100%,
VU>> прокатывает ли (1)?
EG> (1) И так всем известно, что заполненный на 100% пул ZFS это
EG> катастрофа
Как выяснилось, не всегда и не везде.
Вобщем, пока двойка...
EG> до его расширения. И именно невозможность заполнения пула на 100%
EG> при использовании резервирования я и хотел проверить.
VU>> 4. Если мы заполняем пул на (почти?) 100%, ему приходят тормоза и
VU>> пушистый зверёк на $\pi$ (Korchmar effect)
EG> Аналогично (1), мне нужно было только подтвердить, что резервирование
EG> даёт возможность стабильной работы. Мне совершенно не интересно
EG> искать способы прострелить себе ногу, я знаю их неисчеслимое
EG> множество
EG> и ещё один ничего не меняет.
Жаль что Korchmar effect нам никто не хочет продемонстрировать.
VU>> И ещё, ты поставил резервирование на корневой датасет, был в этом
VU>> какой-то скрытый смысл?
EG> Смысл был в том, чтобы после создания пула с резервированием на
EG> корневом
EG> датасете больше не думать о резервировании, создавая рабочие датасеты
EG> как и прежде.
Понятно, то есть просто так. Меня это удивило, просто потомучто считается плохом тоном.
Regards,
Vova
--- Msged/BSD 6.2.0
* Origin: Permission denied (2:5030/257)
|
