LINUX.ORG.RU

как правильно работать с zfs?

 


0

1

В руководстве gentoo создаются разделы, а внутри разделов создаются zfs. Это вообще правильно? Допустим, мне нужно:

/ - 50gb
/home - всё остальное

Как это правильно сделать? Может лучше сделать пул на весь диск, в нем сделать поинты и сделать на них квоты? Как правильно работать с диском, чтобы в случае чего можно было сделать ресайз или сделать отдельно сжатый раздел и тд?

★★★

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

Ответ на: комментарий от Minona

личный опыт.

Аналогично. На FreeBSD SWAP в ZVOL несколько лет и не жужжит.

Плюсы: возможность сжатия данных в ZVOL одним из алгоритмов сжатия ZFS, поддержка контрольных сумм, все активные tmpfs в системе конкурируют за пространство SWAP, если оперативной памяти станет не хватать.

iZEN ★★★★★
()
Ответ на: комментарий от Minona
% zfs create -V 16G poolname/swap
% zfs set compress=lz4 poolname/swap
% zfs set checksum=on poolname/swap
% zfs set org.freebsd:swap=on poolname/swap
% swapon /dev/zvol/poolname/swap
% swapinfo
Device          1M-blocks     Used    Avail Capacity
/dev/zvol/poolname/swap     16384        0    16384     0%
iZEN ★★★★★
()
Ответ на: комментарий от iZEN

а теперь сделай так, в консоли, ибо графика вылетит:

в одной включаешь top -s 1

в другой набираешь:

while 1
tail /dev/zero &
end

переключаешься на top и наблюдаешь.

у меня система встала колом на 56% Inuse Swap

если своп лежит на обычном разделе или выключен, система работает…

это в фряхе

в линуксе (а конкретно в предпоследнем проксмоксе, последний не тестил) если включить своп в zvol и нагрузить оперативку то гарантировано получишь кернел-паник.

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

у меня система встала колом на 56% Inuse Swap

Очевидно, закончилось место в SWAP до отображения факта.

если своп лежит на обычном разделе или выключен, система работает…

Но невыносимо медленно.

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

Очевидно, закончилось место в SWAP до отображения факта.

нет, не очевидно.
когда своп на разделе, top показывает 100% Inuse, но при этом ничего не зависает, информация продолжает обновляться.
в случае с zvol зависает все.
даже перестают сыпаться в системную консоль сообщения out of swap space.

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

хехе..
посмотрел как создается rpool/swap в OmniOS:
zfs create -V 2G -b 4096 -o logbias=throughput -o sync=always -o primarycache=metadata -o secondarycache=none rpool/swap
сделал также в FreeBSD
залипания есть и довольно продолжительные, по 2 мин бывает.
но наглухо виснуть перестало.. чудеса =)

Minona ★★☆
()

Создаешь пул, внутри пула создаешь датасеты. В /etc/fstab ничего писать не нужно. Не забудь параметр --zfs для genkernel

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

Ну, с такими настройками ZVOL мне система пишет, что размер блока (4096) неплохо бы удвоить до нормальной принятой величины, а не как тут. Не стал спорить, удвоил. Также включил сжатие lz4 и проверку контрольных сумм (а то мало ли что). Размер выбрал 8G при 16 ГБ оперативки.

И поведение системы (после перезагрузки и старта) сразу изменилось: SWAP не начинал заполняться пока объём занятой оперативной памяти не превысил 92% при компиляции Chromium из порта FreeBSD. В некоторый момент, примерно на 20% прогрессе, все процессы сборки замедлились - после пяти часов система смогла откомпилировать лишь 58% исходников (обычно сборка Chromium в памяти занимает 3-3,5 часа). При этом SWAP был занят на 100%, а оперативка занята всего лишь 3 ГБ. Ощущение такое, что сборка остановилась и чего-то ждала. Десктопные приложения и процессы, за исключением момента начала компиляции, вполне себе сохраняли отзывчивость, мышь бегала без рывков. Не дождался окончания сборки - вырубил - такое невозможно терпеть. Это растянется на сутки, если не больше. Нужно будет попробовать увеличить размер SWAP, сделать его равным или большим размера оперативки.

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

хм.. хз почему у тебя изменился момент начала заполнения свопа
эти параметры указывают системе что данные в своп пишутся: синхронно, без использования ZIL, не кэшируются - вполне логично скидывать в своп именно так.
но синхронная запись медленная, да =)

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

Пару сотен мегабайт SWAP всё же был занят в начале процесса сборки. Х.з. чем.

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

На вновь организованном SWAP объёмом 18 ГБ под конец компиляции заполненность ОЗУ — 9 ГБ из 16, SWAP — 5 ГБ из 18. Время компиляции и сборки пакета chromium-92.0.4515.159_1 на tmpfs составило 189 минут (процессор Ryzen 1800X), что довольно неплохо в сравнеинии с предыдущими вариантами размещения SWAP в ZVOL.

iZEN ★★★★★
()

А зфс Вам в дженту для чего? Какие задачи решаете? Тем более в / ?!

anonymous
()
Ответ на: комментарий от Minona

ну так а что ты не покажешь где надо смотреть?

а пока ты судорожно ищешь, предлагаю посмотреть на вызов zio_alloc_zil и zio_free_zil во время синхронной записи на созданный вышеуказанным способом zvol, даже однострочник тебе принёс

dtrace -n '*zil:entry {@[probefunc]=count();}'

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

ладно, ты победил =)
в мануале написано, что он выключает использование slog.
я думал что и zil тоже, оказалось нет; из блога оракла:«Data flowing through a logbias=Throughput dataset is still served by the ZIL.»

кстати, раз ты спец по сорцам соляры.
скажи, какой смысл в параметре logbias=throughput, если пул состоит только из SSD?

Minona ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.