Как настроить Linux для кэширования файловых метаданных в соответствии с предпочтениями содержимого?

Я хотел бы настроить систему так, чтобы она использовала большую часть оперативной памяти для кэширования метаданных файловой системы, но лишь небольшую сумму для кэширования с возможностью чтения / записи и предварительной выборки файлов. В идеале я хотел бы иметь возможность просматривать файловую систему (насколько она умещается в ОЗУ), не раскручивая диски, пока я фактически не открою файл.

Вот подробности:

У меня самодельный файловый сервер. У него пять дисков объемом LVM около 9 ТБ, но только 4 ГБ ОЗУ. Поскольку сервер ничего не делает, то обслуживает файлы, большая часть оперативной памяти используется для кэширования. («Бесплатные» отчеты 3.4G из 3.9G используются для кэширования.)

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

Конечно, если диски откручиваются при открытии папки в моем файловом менеджере, возникает задержка, в зависимости от того, какой диск вращается. Просто это не страшно. Но в зависимости от того, где я смотрю, это может произойти несколько раз подряд, если LVM распространил метаданные для каждой подпапки на разных дисках.

Я подозреваю, что Linux в основном заполняет свой кэш содержимым файлов и, возможно, предварительно извлеченными данными. Кеширование не очень полезно, если не считать нескольких МБ для обеспечения плавного воспроизведения; если бы я только посмотрел фильм, я, вероятно, не буду смотреть его снова в ближайшее время. Предварительная загрузка, если это произойдет, также совершенно бесполезна в моем случае , после нескольких мегабайт.

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

При открытии файла все равно будет задержка, но это нормально. Сравните «клик; ждать ; нажмите; ждать ; нажмите; ждать ; играть в; смотреть »с« щелчком »; нажмите; нажмите; играть в; ждать ; часы". Первый невероятно расстраивает; последнее почти ожидаемо.

Примечания:

1. Если это имеет значение, ядро ​​3.2, ОС Debian, том lvm2, а FS - ext4.

2. Единственная причина замедления - шум ночью; в противном случае сервер работает постоянно. (Я сделал его настолько маломощным, насколько это разумно.) Задержка замедления варьируется в зависимости от времени суток.

3. Жесткие диски предназначены только для носителей. ОС находится на отдельной (маленькой) флешке. (Это означает, что любые задержки ускорения происходят из-за данных, а не только потому, что им нужно что-то /usrили что- то в этом роде . Я мог бы сэкономить несколько ГБ, если это каким-то образом поможет с моей проблемой.

4. Разумное влияние на производительность не имеет большого значения. В любом случае диски быстрее моей сети.

Чтобы контролировать, как Linux кеширует вещи, обратитесь к этому https://www.kernel.org/doc/Documentation/sysctl/vm.txt

В частности, посмотрите на vfs_cache_pressure, вы, вероятно, хотите действительно низкое значение или, возможно, даже ноль (хотя 1 звучит немного безопаснее для меня):

vfs_cache_pressure
------------------

Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
never reclaim dentries and inodes due to memory pressure and this can easily
lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.

Также вы можете захотеть изменить swappinessтак, чтобы вы никогда не меняли данные или делали так, чтобы это происходило только в крайних случаях.

Эта drop_cachesопция может быть полезна для явного удаления данных, которые вы больше не хотите кэшировать.

Я уверен, что, возможно, есть другие варианты, которые могут помочь, поэтому просмотрите документацию ядра.

Чтобы применить их, я бы добавил настройки, которые вы хотите изменить, /etc/sysctl.confили то, что ваша ОС должна восстановить их при загрузке.