Проясните по rapiddisk

Чем тебя page cache не устроил?

В Linux из коробки нормально работающий кэш файловой системы («page cache»). Любые файлы, прочитанные с hdd, будут храниться в памяти до тех пор, пока в RAM для них хватает места. Ядро стремится сбросить неиспользуемые данные программ в своп, чтобы кэш занимал как можно большую часть оперативки, и обычно это много гигабайт.

Для дисков больше 4 Тб ты в RAM ничего особо не накэшируешь. До 4 Тб включительно HDD использовать смысла, SSD стоят недорого.

Дык известно, красноглазия маловато.

А вам оно зачем? Родного кэширования чем не хватает?

Хотелось бы сделать быстрый кеш большого размера(скажем, 10Гб+) под такие кейсы:

1. очень быстрая скорость копирования. Я в mc ставлю job копировать и оно много мелких файлов быстро в рам копирует. Я дальше продолжаю работать, а оно пусть там хоть 10 минут прочухивается(скидывает) на hdd. Вариант с background job - это чуть-чуть другое

2. вариант для докера. Понятно, что читать оно будет до кэширования со скоростью hdd, но потом, когда оно закешируется - возможно пересборки docker-compose будут на уровне твердотельного накопителя. Как вариант - можно взять 96 или 128Гб озушки(сейчас стоит 64), вместо покупки твердотельного накопителя под docker-пересборки

Просто выкинь HDD. Или тебе доплачивают за их использование?

Как вариант - можно взять 96 или 128Гб озушки(сейчас стоит 64), вместо покупки твердотельного накопителя под docker-пересборки

Использую tmpfs для директории docker’a, идеально и чистить не нужно

очень быстрая скорость копирования. Я в mc ставлю job копировать и оно много мелких файлов быстро в рам копирует. Я дальше продолжаю работать, а оно пусть там хоть 10 минут прочухивается(скидывает) на hdd. Вариант с background job - это чуть-чуть другое

Так оно читаться в RAM будет 10 минут, а потом 10 минут скидываться. Без такой задержки оно читается и пишется в одно время, если носители разные, соответственно весь процесс занимает 10 минут, может 11, но не 20. Или вам надо на одном и том же HDD постоянно много файлов копировать? Зачем?

вариант для докера. Понятно, что читать оно будет до кэширования со скоростью hdd, но потом, когда оно закешируется - возможно пересборки docker-compose будут на уровне твердотельного накопителя.

Оно так из коробки. Встроенный механизм Page Cache это позволит. Главное, чтоб оперативы «свободной» было достаточно.

Как вариант - можно взять 96 или 128Гб озушки(сейчас стоит 64), вместо покупки твердотельного накопителя под docker-пересборки

Ради какой цели? Просто денег некуда девать, или есть какой-то ещё смысл в этом?

P.S. лучше и рамы взять побольше и SSD тоже.

Яснопонятно. Всем спасибо за внимание!

Я в mc ставлю job копировать и оно много мелких файлов быстро в рам копирует.

Если эти файлики не закешированы, то оно не «быстро в рам копирует», а со скоростью чтения этих файликов с носителя.

Я дальше продолжаю работать, а оно пусть там хоть 10 минут прочухивается(скидывает) на hdd.

facepalm.jpg Вы робите в textmode only и спецом ограничили только одним tty?

Пытался подобное сделать посредством lvm, lvmcache в zram. Любое аварийное завершение - полная потеря данных. Да и собирать lv каждый раз при запуске - тот еще квест. Еще логика кеширования мутная, что я почти не заметил разницы в скорости.

P.S. лучше и рамы взять побольше и SSD тоже.

Эт точно! Я так и поступил несколько лет назад. Дополню и если есть куда втыкать, то брать nvme.

очень быстрая скорость копирования <…> а оно пусть там хоть 10 минут прочухивается(скидывает) на hdd

Ядро и так умеет писать байты на диск в бэкграунд-потоке. Настрой по вкусу значения vm.dirty_background_ratio, vm.dirty_ratio и, в особенности, vm.dirty_expire_centisecs. Минус в том, что это будет влиять на всю систему, а не на отдельный раздел.

вариант для докера. Понятно, что читать оно будет до кэширования со скоростью hdd, но потом, когда оно закешируется - возможно пересборки docker-compose будут на уровне твердотельного накопителя.

Ну это обычное поведение page cache, если хватает памяти на все файлы, то всё работает даже не со скоростью SSD, а быстрее.

если хватает памяти на все файлы, то всё работает даже не со скоростью SSD, а быстрее

В риалтайме прочитать много мелких файлов оно не сможет быстрей скорости hdd. Закешированные - да, но не закешированные - нет

Кстати, а у тебя есть своп-раздел (или хотя бы файл)? Если нет, то он обязательно нужен, а если есть, то возможно стоит увеличить vm.swappiness, вплоть до 100. Тогда page cache сможет использовать больше рамы и веселее перемалывать десятки гигов докерофекалий.

Ну так они после первого чтения закэшируются и будут читаться быстро.

У меня при 64гб стоит такое:

sysctl vm.dirty_expire_centisecs vm.dirty_background_ratio vm.dirty_ratio vm.swappiness
vm.dirty_expire_centisecs = 30000
vm.dirty_background_ratio = 20
vm.dirty_ratio = 25
vm.swappiness = 60

Что-то оно не со скоростью ssd работает в целом

очень быстрая скорость копирования <…> а оно пусть там хоть 10 минут прочухивается(скидывает) на hdd

Ещё вариант: использовать ФС с асинхронной записью.

btrfs? =)

btrfs?

Не на HDD.

Если на диск пишется много гигабайт данных, то vm.dirty_ratio можно поставить побольше, чтобы запись подольше продолжалась в фоне не блокируя процессы. А vm.dirty_background_ratio наоборот, уменьшить, чтобы фоновая запись начиналась раньше, а не ждала заполнения 20% оперативки или таймаута.

А вот тут навскидку не подскажу, надо поизучать тему и возможно потыкать на практике. Такое любят делать в фс, ориентированных на флэшки (например ubifs и f2fs).

Мне представляется, что такую фичу можно прикрутить к любой фс с помощью device mapper, а может быть, кто-то это уже сделал.

Называется «control freak»