Влияние высокого отношения каталога к файлу на XFS

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

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

Поэтому правильное раннее проектирование в порядке.

На этой неделе файлы основаны на следующем примерном макете:

$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file

Что дает каталоги, которые выглядят примерно так:

0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file

Причиной разбиения md5sum является избежание проблемы "большой стопки файлов / каталогов в одном каталоге". Из-за фрагментирования md5sum это означает, что 1 файл приводит к созданию 8 каталогов. Это имеет довольно четкие последствия для inode, но мне неясно, какими будут эти последствия для XFS, как только мы перейдем к масштабу.

Каковы последствия?

Кстати, сейчас это ядро ​​2.6.32, CentOS 6.2 (это может измениться, если потребуется).

В тестировании я создал том xfs со значениями по умолчанию и не использую опции монтирования. Это, чтобы выкурить проблемы рано. noatime это что-то легкое, поскольку нам это не нужно. Общая настройка XFS - это еще одна проблема, которую мне нужно решить, но сейчас меня беспокоит эффект умножения метаданных, который мы разработали прямо сейчас.

Я уже знаю, каким будет лучшее решение, я просто не знаю, есть ли у меня повод, чтобы добиться изменений.

Поскольку md5sums значительно уникальны по первым цифрам, а отдельные подпроекты редко превышают 5 миллионов файлов, мне кажется, что нам нужны только первые два блока. Который дал бы макеты как:

0123456/001/0e15/a644/897219acb4b597f651d69a4d/file

Полностью заполненный первый и второй уровни будут иметь 2¹⁶ каталогов первого уровня и 2¹⁶ каталогов второго уровня в каждом каталоге первого уровня, в общей сложности 2³² каталога на томе.

Таким образом, гипотетический подпроект на 5 миллионов файлов будет иметь 2¹⁶ каталогов первого уровня, примерно 76 (+/- 2) каталогов второго уровня в каждом и один или два каталога третьего уровня в каждом каталоге второго уровня.

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