Возможен ли RAM диск с синхронизацией записи на HDD?

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

dd if=/dev/zero of=/path-to-filesystem-on-hdd bs=1M count=SIZE_IN_MEGS
mkfs ...
# кешируем весь образ в оперативной памяти перед монтированием
cat /path-to-filesystem-on-hdd > /dev/null
# монтируем
mount -o loop /path-to-filesystem-on-hdd /mountpoint

Единственный минус - время «прогрева» кеша зависит от максимального размера ФС.

Я экспериментировал c /var/lib/dkms в памяти. При загрузке tmpfs монтировалась поверх каталога, затем предварительно упакованное содержимое каталога распаковывалось в tmpfs, а при выключении содержимое tmpfs упаковывалось в архив и сохранялось на диск. Для этого нужны либо init-скрипты, либо юниты systemd.

Просто смонтируй диск, оно так и будет работать. Чтобы скопировать содержимое диска в память, запусти find /path | xargs cat > /dev/null

Я хомяк в tmpfs монтирую так:

piyavking@hata: ~ $ cat /etc/fstab | grep home
tmpfs           /home           tmpfs   defaults,rw,size=4G             0       0

плюс к этому обустроил системд службу, которая при загрузке копирует /piyavking в /home/piyavking. После чего делаю с ним всё, что захочу, и читаю, и пишу.

Синхронизирую из памяти на диск вручную - просто перед перезагрузкой или по повелению левой пятки беру mc и «копирую новые» обратно из /home/piyavking в /piyavking. Перегружаюсь не часто.

Если хочется автоматики - прикрути какого-нибудь rsync демона, пусть по расписанию тебе файло обновляет...

Чтобы скопировать содержимое диска в память, запусти find /path | xargs cat > /dev/null

Выглядит круто, я хочу понять, но не могу. Ты не мог бы немножко раскрыть тему?

Элементарно. Тут задействуется механизм кэширования, который является частью ядра. Однострочник читает в /dev/null данные, а ядро обращения к файлам кэширует в памяти, вот и вся хитрость.

Но зачем, если есть bcachefs?

И тоже какое-то шаманство, которое стало любопытно. Поясни пожалуйста, немножко поподробнее эти магические строчки.

Вовсю практикую tmpfs, и было бы обидно что-то делать не так. Разве простого cp недостаточно?

Каждое слово в отдельности вроде понятно, но на этом всё. Со мной частенько так. Так, стоп, что-то начало прорастать. Помедитирую. Спасибо!

Блочное устройство в памяти (но как называется сам найди) + mdadm зеркало из этого устройства и раздела на диске.

Уже давно так и есть. Всё идет через многочисленные кеши-буфера. Следствие этого, многочисленные темы о неумении писать флешки.

И постоянно запускать этот cat, чтобы из ОЗУ кешем других файлов не вытеснилось?

беру mc и «копирую новые» обратно

А удаляет файлы кто?

Плюс, при наличии swap'а, файлы с tmpfs могут там оказаться. Может ТС важно именно гарантированный «мнгновенный» доступ к любому файлу из этого каталога.

https://docs.kernel.org/admin-guide/index.html#block-layer-and-filesystem-administration

есть вот такие штуки, например, https://github.com/ecdye/zram-config

которые через OverlayFS монтируют RAM-диск поверх каталога. но синхронизация там вызывается вручную. впрочем, наверное, её можно навесить и на какой-нибудь крон.

в параметрах монтирования можно увеличить commit - это время через которое данные сбрасываются на диск

А удаляет файлы кто?

Свапа нету, у меня в хомяке только конфиги и небольшой tmp, я редко что-нибудь удаляю, а если удаляю, то знаю, что удаляю. Конечно у ТС свои вкусы и они тоже несколько специфичны, но... к него tmpfs, у меня tmpfs. Я поделился своим обустройством, вдруг пригодится. Хотя бы в качестве примера, как не надо делать)

как подружить

да фиг его знает чего там у тебя… у меня например система вырубается так

#!/bin/bash
read -p "Shutdown? " -n 1 -r
echo
if [[ ! $REPLY =~ ^[YyНн]$ ]]
then
    exit 1
fi
loginctl poweroff

сие на горячие забито и можно в скрипт добавить скорировать любое куда захочу - напрмиер из tmpfs на диск, но я делаю наоборот - при старте из диска копирую в tmpfs

export XDG_CACHE_HOME="/tmp/.cache"
[ -d "${XDG_CACHE_HOME}" ] || (
        mkdir -p "${XDG_CACHE_HOME}"
        chmod 0700 "${XDG_CACHE_HOME}"
)
cp -ax $HOME/.cache /tmp
export XDG_CONFIG_HOME="/tmp/.config"
[ -d "${XDG_CONFIG_HOME}" ] || (
        mkdir -p "${XDG_CONFIG_HOME}"
        chmod 0700 "${XDG_CONFIG_HOME}"
)
cp -ax $HOME/.config /tmp
export XDG_DATA_HOME="/tmp/.local/share"
[ -d "${XDG_DATA_HOME}" ] || (
        mkdir -p "${XDG_DATA_HOME}"
        chmod 0700 "${XDG_DATA_HOME}"
)
export XDG_STATE_HOME="/tmp/.local/state"
[ -d "${XDG_STATE_HOME}" ] || (
        mkdir -p "${XDG_STATE_HOME}"
        chmod 0700 "${XDG_STATE_HOME}"
)
cp -ax $HOME/.local /tmp

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

Чтобы скопировать содержимое диска в память, запусти find /path | xargs cat > /dev/null

Лучше fastwalk -r /path. Будет гораздо быстрее/эффективнее.

https://github.com/andikleen/fastwalk

Чтобы скопировать

Лучше

чего так сложно? cp уже не катит?

Нет, не катит. Речь ведь лишь о чтении файлов в кэш (в памяти), а не в какое-то место в ФС.

https://github.com/graysky2/anything-sync-daemon

А зачем тебе вообще? Какую проблему/задачу ты решаешь?

речь о чтении

не понимаю такой речи, вот например cp -ax $HOME/.cache /tmp копирует .cache в tmp которое живет в tmpfs и получается fastwalk -r $HOME/.cache /tmp сделает то же самое? ну только лчше разумеется? или я ошибаюсь?

Настрой прогу через cgroup чтобы ей выделялось памяти не меньше определённого, файловый кэш так тоже учитывается, вроде бы.

Плюс, при наличии swap'а, файлы с tmpfs могут там оказаться. Может ТС важно именно гарантированный «мнгновенный» доступ к любому файлу из этого каталога.

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

и получается fastwalk -r $HOME/.cache /tmp сделает то же самое? ну только лчше разумеется? или я ошибаюсь?

Да, ошибаешься. Ты почитай, на что я отвечал, и аналогом чего вариант с fastwalk является.

fastwalk ничего никуда не копирует, у него нет source и destination, все аргументы равнозначны. Результатом твоей команды будет просто чтение всех файлов содержащихся в $HOME/.cache и всех файлов, сожержащихся в /tmp. То есть, то же самое, что будет, если сделать find $HOME/.cache /tmp | xargs cat > /dev/null, но лучше (быстрее).

то знаю, что удаляю.

Но, удалять файл, надо дважды? Один раз из tmpfs, а второй с диска.

В общем, получается, что либо копировать файлы в tmpfs (которую в последних ядрах можно монтировать с опцией noswap) и переодически синхать на диск, либо md raid1, с опцией --write-mostly для диска.

Для первого варианта уже написаны велосипеды (zram-config, asd — anything-sync-daemon), но синхронизация не постоянная. А во втором варианте, получается, отдельная файловая система и нужно писать скрипты (losetup, mdadm), которые этот raid при старте будут собирать. И неизвестно какие там подводные камни обнаружатся.

И постоянно запускать этот cat, чтобы из ОЗУ кешем других файлов не вытеснилось?

Думаю, да, если это важно.

Я бы тоже, на самом деле, хотел такое. Но вроде нет такого в линуксе. На самом деле у меня ощущение, что tmpfs быстрей главным образом потому, что игнорирует fsync-и. Куча программ, особенно браузеры с их sqlite-ами под капотом, грешат тем, что долбят диск fsync-ами и это делает I/O медленным. tmpfs это всё игнорирует, поэтому такой код на них работает гораздо быстрей. Может быть, если бы получилось отключить fsync для такого каталога, то оно и заработало бы со скоростью tmpfs, в то же время не теряя данные в штатных ситуациях.

Кажется тебе нужен бкеш, хотя на кой если у тебя этим уже ядро занимается?

Ну да. Но происходит это редко и в ~/tmp в основном.

если бы получилось отключить fsync для такого каталога

так есть же флаг sync в /etc/fstab, вроде он это и делает?

Идеальное решение зависит от применения. Для себя я запиливал велосипед на rsync - дата была некритичная, мне нормально было. Но не факт, что у тебя так же будет.

есть такое - рейд массив из RAM и HDD.
https://vixdevelop.blogspot.com/2016/09/zraid.html

вааапчето говоря, линуха все файлы кеширует, а кеши из памяти не удаляет помаксимуму :) тут тебе уже подсказывали прогрев кеша чтение необходимых файлов. ну и РАМы должно сильно больше объема интересующих файлов.

Всем спасибо! Пока остановился на raid из рамы и харды :) т.к. самое простое. Посмотрим как себя поведёт...

Тебе наверное надо это
https://wiki.archlinux.org/title/Firefox/Profile_on_RAM

Или это
https://wiki.archlinux.org/title/Profile-sync-daemon

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

положи директорию на отдельный раздел и сделай зеркало между этим разделом и RAM диском.

но вообще-то дисковый кеш так и работает, не обязательно велосипедить.

Для этого есть vmtouch :-)

так есть же флаг sync в /etc/fstab, вроде он это и делает?

Нет, он совсем не это делает. С этим флагом каждая запись в файловую систему немедленно отправляется на диск. Это может быть полезно, например, для флешек, чтобы выдёргивать их без размонтирования, как это делается в Windows (хотя вроде в Windows это как-то по-другому сделано, но не суть). Без этого флага всё работает как обычно - все записи сначала собираются в оперативной памяти и с определенной периодичностью, что-то вроде раз в 30 секунд - записываются на диск. fsync заставляет записать всё на диск немедленно. Но сделать так, чтобы fsync ничего не делало - на уровне опций монтирования - нельзя. Только дорабатывать ядро и добавлять там такой функционал. Доработки, думаю, были бы тривиальные, но пока никто такого не сделал, ну или по крайней мере не заапстримил.

Для userspace есть библиотечка libeatmydata, которая через перегрузку libc позволяет отключить вызов fsync. Но это не вполне надежная технология.

Да как бы ее - ram у меня 256 Гб.
Но вот стандартный файловый кэш, с raid0 из 2х дисков (для скорости) и ext4 все равно спустя какой то время или действия теряет в «скорости».
Я собираю большое дерево исходников что то правлю и иногда это вызывает много зависимостей для пересборки.
Так вот полная сборка после clean занимает сейчас с raid и надеждой на файловый кэш, даже после «подготовки» около часа, при этом видно, что загрузка io очень велика, а ядра процессора «простаивают».
После переноса исходного кода на tmpfs полностью, сборка стала занимать около 20минут, при этом все время 100% загрузка процессорных ядер.
3х кратный прирост в скорости сборки меня устраивает.

Вчера я натянул zramraid. Но еще пока не проверил скорость сборки, пока не до этого...

Имя им — легион, ещё был preload, да и другие подобные демоны. Но они кешируют только файлы, делая им mmap() а каталоги нет. Кеш каталога вымывается и через некоторое время после запуска vmtouch каталог со 100500 файлов опять читается долго.

Но они кешируют только файлы, делая им mmap() а каталоги нет.

Ну как сказать...

pinkbyte@oas1 ~ $ cat /etc/local.d/vmtouch.start 
#!/bin/bash
# Add binaries to RAM cache for speed
vmtouch -d -L /usr/bin /bin

strace -f не даст соврать - проходит по всем файлам в каталоге(но не во вложенных)

Единственное что - не уверен, что при изменении содержимого каталога он перечитывает закэшированные файлы

сборка стала занимать около 20минут

tmpfs не только скорость чтения, но и скорость записи подняла существенно.

И, зачем для компиляции синхронизировать tmpfs и диск? Хотите выключать комп в процессе сборки?

Это величины совсем другого порядка, чем я предпологал, ты ведь ни словом, ни намёком. Тем не менее. А что, если «живая система». По определению, у неё все в оперативке, ей просто некуда скидывать…

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

нет, для флэшек это совсем не полезно и даже вредно. у них ресурс ограничен. поэтому и делаются оверлеи, а потом синхронизация. никогда не берите пример с маздая.

нет, для флэшек это совсем не полезно и даже вредно.

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

ну да, а потом они бегут на форумы и вопрошают: ой, а что это у меня флэшка перестала определяться системой? :)

Для userspace есть библиотечка libeatmydata, которая через перегрузку libc позволяет отключить вызов fsync. Но это не вполне надежная технология.

Уже пару лет браузер запускаю через eatmydata, и пока что проблем не было.