Согласно этому бумага в Стоге сена Facebook:
"Из-за того, как устройства NAS управляют метаданными каталогов, размещение тысяч файлов в каталоге было крайне неэффективным, поскольку блок-карта каталога была слишком большой для эффективного кэширования устройством. Следовательно, для получения одного образа обычно требовалось более 10 дисковых операций. После уменьшения размеров каталогов до сотен изображений на каталог, результирующая система по-прежнему будет выполнять 3 дисковые операции для извлечения изображения: одна для чтения метаданных каталога в память, вторая для загрузки inode в память и третья для чтения содержимое файла."
Я предполагал, что метаданные и индексный дескриптор файловой системы всегда будут кэшироваться в ОЗУ операционной системой, а для чтения файла обычно требуется только 1 дисковый ввод-вывод.
Является ли эта проблема «несколько дисковых операций ввода-вывода для чтения одного файла», описанная в этом документе, уникальной для устройств NAS, или у Linux такая же проблема?
Я планирую запустить Linux-сервер для обслуживания изображений. В любом случае я могу минимизировать количество операций ввода-вывода на диск - в идеале, чтобы ОС кэшировала все данные каталога и индексного дескриптора в ОЗУ, и для каждого чтения файла потребуется не более 1 ввода-вывода на диск?
У Linux такая же «проблема». Вот это статья моего студента, опубликованная два года назад, в которой показан эффект на Linux. Множественные операции ввода-вывода могут поступать из нескольких источников:
В обычном шаблоне ввода-вывода кэширование действительно эффективно, и индексы, каталоги и блоки данных распределяются таким образом, чтобы уменьшить количество обращений. Однако обычный метод поиска, который фактически используется всеми файловыми системами, плох для сильно рандомизированного трафика.
Вот несколько идей:
1) Кеши, связанные с файловой системой, помогают. Большой кеш поглотит большую часть чтения. Однако, если вы хотите установить несколько дисков в машину, соотношение дискового пространства к ОЗУ ограничивает объем кэширования.
2) Не используйте миллионы маленьких файлов. Объедините их в файлы большего размера и сохраните имя файла и смещение в файле.
3) Поместите или кэшируйте метаданные на SSD.
4) И, конечно же, используйте файловую систему, которая не имеет полностью анархического формата каталогов на диске. Readdir не должен занимать больше, чем линейное время, а прямой доступ к файлу в идеале - только логарифмическое время.
Сохранение небольших размеров каталогов (менее 1000 или около того) не должно так сильно помогать, потому что вам потребуется больше каталогов, в которые необходимо кэшировать.
Это зависит от файловой системы, которую вы планируете использовать. Перед чтением файловой системы данных:
Если папка содержит огромное количество файлов, это большая гарантия кеширования.
Вероятно, вы не сможете хранить все данные каталога и индексного дескриптора в ОЗУ, поскольку у вас, вероятно, больше данных каталогов и индексных дескрипторов, чем в ОЗУ. Вы также можете не захотеть, так как эту оперативную память лучше использовать для других целей; в вашем примере с изображением, разве вы не предпочли бы, чтобы данные часто используемого изображения кэшировались в ОЗУ, чем запись в каталоге для редко используемого изображения?
Тем не менее, я думаю, что vfs_cache_pressure ручка используется для управления этим. «Когда vfs_cache_pressure = 0, ядро никогда не будет восстанавливать данные и индексные дескрипторы из-за нехватки памяти, и это может легко привести к нехватке памяти».