FreeBSD, zram

# mdconfig -a -t malloc -o compress -o reserve -s 512m -u 7
# swapon /dev/md7
либо
# mount /dev/md7 /mnt/ramdrive

оно?

mdconfig -a -t malloc -o compress -o reserve -s 512m -u 7

Вроде оно, спасибо, а какой алгоритм используется для сжатия?

Вроде оно, спасибо, а какой алгоритм используется для сжатия?

Вродь zip, но не уверен.

Выглядит намного вкусней чем в linux. Можно ли сделать нормальный zswap без распаковки в обе стороны, чтобы неактивные страницы в сжатом виде уходили в swap-файл?

Так ведь ARC в памяти сжатый.

Я не знаю, что такое ARC. Кривость zswap в том, что страницы сжимаются в zswap, и если надо сбросить на диск, то они разжимаются (прикидывается шлангом). При интенсивной работе с свапом, zswap - это дополнительный бесполезный тормоз из-за двойной работы (сжатие-разжатие с нулевым эффектом), если недодумается напрямую сбрасывать на диск. А хочется чтобы был сжатый swap с сжатым кешем в памяти.

mdconfig -a -t malloc -o compress -o reserve -s 512m -u 7q

А теперь сделай вместо swapon newfs, закинь туда хорошо сжимаемые большие файлы (можно dd if=/dev/zero) и удивись тому, что памяти (wired) все равно жрется ровно столько, сколько занимет непожатый файл.

Я не знаю, что такое ARC

Это прибитый гвоздями к ядрам Linux и FreeBSD кэш ZFS.

А хочется чтобы был сжатый swap с сжатым кешем в памяти.

Почему не использовать zram? Если он свопится (должен), то будет это делать в сжатом виде.

Почему не использовать zram? Если он свопится (должен), то будет это делать в сжатом виде.

Куда будет СВОПиться СВОП в zram? Я вижу бесконечную рекурсию

и удивись тому, что памяти (wired) все равно жрется ровно столько, сколько занимет непожатый файл

И что тут аномального? В wired памяти находится все что угодно пока памяти хватает.

Можно ли сделать нормальный zswap без распаковки в обе стороны, чтобы неактивные страницы в сжатом виде уходили в swap-файл?

Не встречал такого функционала. Скорее всего нельзя.

Вот так получилось:

# dd if=/dev/zero of=disk.img count=1024 bs=1048576
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 0.360115 secs (2981663155 bytes/sec)
# mdconfig -u md1 -o compress -o async -f disk.img
# swapon /dev/md1
# swapinfo 
Device          1M-blocks     Used    Avail Capacity
/dev/md1             1024        0     1024     0%
Total                1024        0     1024     0%

В то, что задействуется памяти как для несжатого файла.
Неверующие могут сделать file-based "-f foo", записать туда «seq 100500» и дернуть hexdump — содержимое там не пожато.

Ну и ковырял я это дело, правда пару лет назад (но с тех пор ничего особого не коммитилось) — кроме самих флагов сжатия ничего толком не нашел, выглядело как заглушка «потом мы добавим фунциональность» …

# mdconfig -u md1 -o compress -o async -f disk.img

Читая ман mdconfig, я не понял: туда сжатые данные записываются или сперва разжимается?

туда сжатые данные записываются или сперва разжимается?

По логике должны записываться сжатые.

По логике должны записываться сжатые.

Что-то я другому анониму больше верю.

выглядело как заглушка «потом мы добавим фунциональность» …

/* Compression doesn't make sense if we have reserved space */

https://github.com/freebsd/freebsd/blob/master/sys/dev/md/md.c#L1355

Наверно нужно убрать -o reserve чтоб сжатие работало.

выглядело как заглушка «потом мы добавим фунциональность» …

Эх, а была надежда...
В общем, спасибо.

А вот интересно: при переносе данных из такого сжатого свопа на блочном устройстве в оперативной памяти обратно в оперативную память, будет ли освобождаться память занятая этим виртуальным блочным устройством?

// Не freebsd'шник

будет ли освобождаться память занятая этим виртуальным блочным устройством?

Работа Фри с мамятью очень отличается от других ОСей. Фря практически все что грузит в память там и оставляет в виде буферов и кешей до тех пор пока есть свободная память. Как только Free стремится к нолю, кеши к которым обращались меньше всего выбрасываются.

По идеи, с -o noreserve должна память освобождаться. А как оно на практике - хз.

less /usr/src/sys/dev/md/md.c Или я туплю или там нет ничего для сжатия. grep MD_COMPRESS /usr/src — задействуется только в md.c и в mdconfig для флагов.

# mdconfig -a -t malloc -o compress -s 512m -u 7
% top 
1301M Wired
% seq 100500000 |dd bs=1m| > /dev/md7                                             
^C0+131090 records in
0+131089 records out
536940544 bytes transferred in 25.095308 secs (21396053 bytes/sec)

% top
 1814M Wired
#mdconfig -d -u7 
% top
1301M Wired

никакой разницы с заполнением «dd if=/dev/urandom».

Или я туплю или там нет ничего для сжатия.

Я тоже нихрена не могу понять из исходников. В мане хитро сказано:

             [no]compress
                     Enable/disable compression features to reduce memory
                     usage.

ARC

Непохо бы его починит, а не заниматся пересмотром сроков поддержки и изнасиованием зфс.

Зачем разработчикам из iX (а больше никто не работает над ZFS в прошивке для плойкиFreeBSD) его чинить, если можно просто поднять минимальные системные требования FreeNAS с 8 до 16 или сразу 32 Гб? :D

Ирония очевидна, но может у разрабов ещё ест профессиональная гордост и уважение к самим себе (то, что на позоватеей они сраи с пробором думаю очевидно).

Еси без петросянства то арк во фре работает. Иногда.

Ну и пробема вед системная. Еси не повезёт схавает 32 гектара и не поперхнётся.