Предпосылки: Кэш Linux VFS будет кэшировать каждый файл, который читается с диска в памяти. Это продолжается до тех пор, пока ОЗУ не заполнится, после чего самые старые файлы удаляются из кеша.
Я использую XenServer с сетевым хранилищем. У моих серверов корневая файловая система находится в сетевом хранилище. У меня также есть локальный диск на каждом хосте XenServer. Мои серверы имеют свои разделы подкачки в этом локальном хранилище. В моем конкретном случае сетевое хранилище загружено, и disk io может работать довольно медленно. У меня такие настройки, потому что локальные диски не используют RAID и не защищены каким-либо образом. Моя система может терпеть сбой локального диска, потому что все, что я потеряю, - это разделы подкачки.
Мне интересно, знает ли кто-нибудь, как заставить Linux заполнить раздел подкачки (помимо ОЗУ) кэшированными файлами? С физическим сервером, использующим все локальные диски, это не дает выигрыша в скорости, но для моих серверов это имеет большой смысл.
Проблема с тем, что вы пытаетесь сделать, заключается в том, что кеш VFS полностью контролируется внутри ядра, и ваше проблемное пространство очень нишевое - в общем, помещение кеша в подкачку полностью нарушает цель кеширования (хотя я согласен ваш вариант использования является допустимым). Я просто хочу сказать, что очень маловероятно, что то, что вы хотите сделать, в настоящее время поддерживается в ядре (и я, конечно, никогда не слышал никаких разговоров о том, что вы хотите сделать, возможно).
Если бы вы использовали более «псевдо» технологию виртуализации, такую как qemu, вы могли бы «перегрузить» память, используемую виртуальными машинами. Таким образом, память, используемая виртуальной машиной, будет более видимой для хоста как «обычная» память процесса, и вы сможете затем использовать пространство подкачки хоста, чтобы выгружать его, когда в нем нет необходимости. Это создает риск замены машины до смерти, если процессам на виртуальных машинах действительно нужна вся эта память или если давление кеша на виртуальных машинах было сильным, но это могло работать с некоторой осторожной настройкой.
Любые попытки управлять такими вещами в пользовательском пространстве вряд ли сработают, потому что кэширование VFS - это все на уровне ядра, и (опять же) варианты использования для управления им в пользовательском пространстве очень нишевые. Если бы это были данные приложения, которые вы пытались кэшировать, вы могли бы предоставить кеш для данных в пользовательском пространстве (если вам это нужно в файловой системе, вы можете использовать FUSE, но хранилище данных для конкретного приложения будет работать лучше), но это много работы (кэширование сделать не так просто) и не будет работать, если вам нужно кэшировать корневую файловую систему.
Если вы все же решите, что это того стоит, я думаю, вы потратите много времени на написание и отладку собственного кода уровня ядра для поддержки этого варианта использования. Вместо того, чтобы обобщать проблему "хранить кеш в свопе" (что сразу же заставит многих людей защититься), может быть проще некий механизм "кэширования устройства SAN", который использует пространство подкачки, а не VFS в -кэш памяти. Заметьте, я говорю «проще», а не «легко» - это все равно будет много работы.
Я был бы готов потратить много усилий (и денег) на улучшение производительности моего NAS / SAN, прежде чем я рассмотрю вопрос модификации ядра - потому что, честно говоря, это даст больше прибыли, чем кэширование . При кешировании ваш начальный доступ всегда будет таким же медленным, как и базовый механизм доступа, и если вы сможете сделать это быстрее, это, вероятно, улучшит воспринимаемую производительность больше, чем медленный начальный доступ с быстрым (нечастым) повторным доступом. Также учитывайте стоимость просто предоставления всем вашим виртуальным машинам целого объема оперативной памяти - вы можете купить много оперативной памяти за месяц или два взлома ядра.