zram с расширением на диск

Если тебе надо, чтоб при переполнении ZRAM всё писалось в своп - tmpfs к твоим услугам. Про ФС, которые сами умеют писать в разные места по мере заполненности блочных устройств не слышал, но что-то такое должен уметь LVM с linear-соодинением физических томов. Но зачем?

Отличная мысль, спасибо, ей и обойдусь. Я не знал, что она при переполнении пишет в своп.

Пока ковырялся с изменением сервиса под tmpfs (что получилось), понял, что надо именно то, что я описал первоначально. У меня своп всего 8Гб на разделе ссд диска (и он все равно всегда пустой так как ОЗУ хватает). Бывают задачи когда в tmp какая-то софтина может распаковать что то значительно больше чем этот объем, тогда и надо то, что я описал. Мне никакого свопа не хватит под некоторые программы и их нужды. В то же время объема раздела на жестком диске, который я использую под данные вполне хватит и я хотел бы просто выделить в нем папку, куда закидывать не влезшее в zram, который примонтирован в /tmp прозрачно для системы. Подошло бы что то вроде unionfs, но не слоеной, а составной, как single в btrfs, но она работает с девайсами или разделами целиком к сожалению (насколько я знаю там просто указать папки нельзя).

Так что если кто то слышал про возможность составить единую ФС из последовательно указанных директорий на диске, подскажите, вопрос остается.

Да, еще можно что бы ФС могла монтировать последовательно разделы и файл, не обязательно папку на диске. Файл вполне устроит.

Короче, на zram делаешь своп дополнительный, чтобы увеличить оперативу, ставишь этому свопу больший приоритет => profit. Я так либроофис и хромиум на генте компилял.

а вообще, как этой zram пользоватся?
А то у меня mount -t zram fff /tmp/ggg не срабатывает.

В гугле забанили? Хотя стоп, в статьях в Интернете советуют для того, чтобы сделать записть в несколько потоков, создавать несколько устройств; либо потому, что дурачки, либо потому, что статьи были написаны тогда, когда нельзя было по-другому. Короче, когда прочитаешь, что для создания устройст(ва|в) zram нужно подключить соответствующий модуль и указать ему количество устройств, почитай man zramctl.

mount -t zram fff /tmp/ggg

как такое вообще могло в голову прийти?

Спасибо, но похоже у меня в jessie этого нету,
никто не в курсе, в Debian Unstable есть?

Что бы не парить мозг есть

https://github.com/vaeth/zram-init

Так же в репах дебиана есть zram-config

Посмотри, там все понятно написано. Я с джита взял основу, а сейчас туда добавляю новую ФС.

Кстати, отвечу на свой вопрос. btrfs позволяет создавать себя прямо в файле на диске. Так что

dd if=/dev/zero of=/mnt/data/harddisk.img bs=1G count=0 seek=40 mkfs.btrfs -d single /dev/zram1 /mnt/data/harddisk.img

Но к сожалению весь этот файл будет лежать на диске постоянно. Пока не придумал как сделать что бы он рос по мере использования.

чего нету?

Подозреваю поможет вот, что

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices

и оттуда:

# Create and mount a filesystem made of several disk images
mkfs.btrfs img0 img1 img2
losetup /dev/loop0 img0
losetup /dev/loop1 img1
losetup /dev/loop2 img2
mount /dev/loop0 /mnt/btrfs

А там можно настроить приоритет? А то будет у тебя ещё на диск писаться, даже когда устройство в раме не заполнено.

Насколько я понял, запись данных ведется последовательно по мере заполнения, а метаданные зеркалируются но это можно отключить. Но я пока подробно не лез, позже залезу. Сама ФС не шибко надежна (проверено многократно...надежда умирает последней :) ), но так как она нужна только внутрисеансово и будет создаваться при каждой загрузке, пойдет.

Там есть

# Don't duplicate metadata on a single drive (default on single SSDs)
mkfs.btrfs -m single /dev/sdb

и

# Use full capacity of multiple drives with different sizes (metadata mirrored, data not mirrored and not striped)
mkfs.btrfs -d single /dev/sdb /dev/sdc

Так что все скорее всего будет реально.

На мой скромный взгляд, вариант сo swap на zram + tmpfs менее костылен (точнее, вообще не представляет из себя костыль).

Как я описал, недостаток в том, что своп ограничен объемом и помещать его на жесткий диск я не хочу. Файл же кинуть на почти терабайтный и все равно почти пустой жесткий диск, не страшно. Хотя можно сделать девайс из loop в файле, на файл сделать swap, подрубить его, а уж поверх использовать tmpfs. В общем я пока повожусь с выбором.

Задачка проста, сделать что бы была возможность сначала писать в zram, а когда место кончится, что бы писалось куда то в другое место и размер этого места был бы ограничен только размером диска. Пока больше вариантов не придумал.

Кстати может подойдет что то вроде aufs/unionfs но я никогда их не смотрел, позже поколупаю.

Да, кажеться aufs2, которая в убунте используется и есть, вполне подойдет, намного лучше всего прочего. Ее и использую, как раз папки объединять умеет и еще много чего. Так что в zram буду ее создавать и отдавать вторым бранчем (там так это называется) папку на жестком диске. Пока не понял как там стратегия записи в бранчи настраивается и работает, но по сути то все равно, так как это просто /tmp и мне просто повозится хотелось, а не просто перенести ее с ssd на жесткий диск :)

мы решили задачу немного иначе, посмотрите может вам подойдет: http://vixdevelop.blogspot.ru/2016/09/zraid.html

zswap

Просмотрел заметку, спасибо. Я в конечном итоге использовал tmpfs что бы в нем сделать файл, второй файл на ssd диске. Эти файлы объединил btrfs-ом в одну фс и ее примонтировал куда мне надо.

/etc/systemd/system/tmp.mount

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=btrfs_tmp.service
After=btrfs_tmp.service

[Mount]
What=/dev/loop0
Where=/tmp
Type=btrfs
Options=defaults,compress=lzo,relatime,noatime,nosuid,nodev,noexec,discard

/etc/systemd/system/mnt-tmpfs.mount

[Unit]
Description=Prepare ramdisk for compressed file image witch btrfs
Before=local-fs.target btrfs_tmp.service tmp.mount
After=systemd-modules-load.service

[Mount]
What=tmpfs
Where=/mnt/tmpfs
Type=tmpfs
Options=defaults,noatime,nosuid,nodev,noexec,mode=1777,size=4096M

/etc/systemd/system/btrfs_tmp.service

[Unit]
Description=Prepare btrfs = tmpfs image+disk image
DefaultDependencies=no
Conflicts=umount.target
Before=tmp.mount
Requires=mnt-tmpfs.mount
After=systemd-modules-load.service mnt-tmpfs.mount

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=/usr/bin/truncate -s 4G /mnt/tmpfs/image0
ExecStart=/bin/mkfs.btrfs -d single -m single /mnt/tmpfs/image0 /mnt/disk/image0
ExecStart=/sbin/losetup /dev/loop0 /mnt/tmpfs/image0
ExecStart=/sbin/losetup /dev/loop1 /mnt/disk/image0
ExecStart=/bin/btrfs device scan /dev/loop0
ExecStart=/bin/btrfs device scan /dev/loop1

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

aufs не подошел. К сожалению он не умеет делить большие файлы между бранчами. Значит, желая записать большой файл, который не влезет в один бранч целиком, ты получаешь сообщение о нехватке места. В общем не подошла мне эта ФС к сожалению.

Может лучше тогда modprobe brd rd_size=1677721, получишь сразу блочное устройство /dev/ram0.

У tmpfs есть преимущества перед просто блочным устройством. Я спецом не изучал но как минимум tmpfs сливает в своп все то, что неактуально и в памяти не нужно на данный момент. Плюс не жрет память пока не надо. Но это сравнивать надо и вспоминать что я там воротил и почему. К тому же оно в таком виде работает уже давно, быстро и стабильно, так что пойдет. Уже нет интереса колупать, все устраивает.

То есть сейчас все данные с этого объединенного Btrfs часть в своп, часть в файл на ссд диске. В конечном итоге все файло может быть вытеснено из памяти. Но экстремальных тестов я особо не делал. Заливал туда здоровенные файлы, оно справлялось. Образ виртуалки туда кидал и прочее. Мне оно надо было для компиляции чего то там и обновления IDE своей у которое это обновление тупо сделано и требует заливки здоровенного файла, который не лез в старый раздел.

Да, кстати. Точка монтирования в моем конфиге /mnt/disk это bcache, с двумя слоями ssd->hdd. Так что пирог тот еще :) Выходит: tmpfs+bcache=btrfs :)