Linux: доступ к тысячам файлов в хэш-каталогах

Question

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

Я выполняю операцию индексации в каждом из этих файлов, так что 4 файла индекса, примерно в 5-10 раз меньше, чем файл данных, создаются рядом с файлом для индексации.

Сейчас я использую иерархию каталогов от ./00/00/00 до ./99/99/99 и я помещаю один файл в конец каждого каталога,
как ./00/00/00/file000000.ext to ./99/99/99/file999999.ext .

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

Answer 1

Распространенная проблема производительности с большими каталогами в ext [34] заключается в том, что он хэширует записи каталога и сохраняет их в порядке хеширования. Это позволяет быстро разрешить определенное имя, но эффективно рандомизирует порядок, в котором перечислены имена. Если вы пытаетесь работать со всеми файлами в каталоге и просто перебираете каждую запись в том порядке, в котором они перечислены, вы вызываете много случайных операций ввода-вывода, что очень медленно. Обходной путь к этому состоит в том, чтобы отсортировать список каталогов по номеру инода, а затем перебрать файлы в порядке от наименьшего к наибольшему номеру инода. Это делает ваш ввод-вывод в основном последовательным.

Answer 2

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

то есть:
md5(test.jpg) дает вам "13edbb5ae35af8cbbe3842d6a230d279"
Ваш файл будет называться «13edbb5ae35af8cbbe3842d6a230d279.jpg», и вы сохраните его в ./13/ed/bb/5ae35af8cbbe3842d6a230d279.jpg, таким образом, учитывая большое количество файлов, вы должны иметь хорошее распределение файлов в папке.

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

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

Answer 3

В принятом ответе на ServerFault Игнасио Васкес-Абрамс говорится:

Если у вас есть дистрибутив, который поддерживает функцию dir_index, то вы можете легко разместить 200 000 файлов в одном каталоге. Я бы держал его на уровне около 25 000, хотя, чтобы быть в безопасности. Без dir_index попытайтесь сохранить его на уровне 5000.

Который я бы принял как предложение

 ./000/file000000 to ./000/file000999
 ./001/file001000 to ./001/file001999
 ...
 ./999/file999000 to ./999/file999999

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

---

Ответы на другой вопрос Stackoverflow говорят

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

Комментатор говорит

Существует ограничение около 32 КБ подкаталогов в одном каталоге в ext3, но ОП говорит о файлах изображений. Нет (практично?) ограничение на файлы в файловой системе ext3 с включенным Dir Index.

Я думаю , что я бы запустить несколько тестов , чтобы увидеть , если организации файлов в подкаталогах было целесообразно для чего - нибудь другого , чем производительность ls Общие правила оптимизации: 1 нет, 2 действительно нет, 3 меры.