В данной ситуации выбор оптимальной файловой системы будет зависеть от наиболее часто выполняемых над файлами операций, потому как количество индексных дескрипторов для журналируемых файловых систем может задаваться при разметке отличным от стандартного.
Мы нашли результаты тестирования нескольких различных файловых систем на одинаковых операциях. Каждая операция была выполнена для 30000 файлов, после чего было взято среднее время выполнения операции. Сам бенчмарк доступен в сети и может быть использован Вами самостоятельно для проведения независимого теста.
https://www.dropbox.com/s/viba8rzdq6uegsq/bench.py?dl=0
Using Linux Kernel version 3.1.7
Btrfs:
create: 53 s
rewrite: 6 s
read sq: 4 s
read rn: 312 s
delete: 373 s
ext4:
create: 46 s
rewrite: 18 s
read sq: 29 s
read rn: 272 s
delete: 12 s
ReiserFS:
create: 62 s
rewrite: 321 s
read sq: 6 s
read rn: 246 s
delete: 41 s
XFS:
create: 68 s
rewrite: 430 s
read sq: 37 s
read rn: 367 s
delete: 36 s
Здесь можно видеть, что по показателям создания и удаления файлов наилучшие результаты демонстрирует ext4 (с подключенным журналом).
Файловая система XFS в данном тесте показала невысокие результаты, однако она всё ещё остаётся популярна для систем, где требуется хранить большие объёмы информации. Также обычно её рекомендуется использовать в нестандартных конфигурациях, потому как изначально она несколько больше заточена под гибкость настройки.
Также по результатам данного сравнительного тестирования отметим, что в ситуации, когда основными многократно повторяющимися операциями являются чтение из файлов и запись в них, а удаление файлов происходит редко, возможным оптимальным выбором будет Btrfs, немного уступающая ext4 в скорости создания файла, однако дающая лучшие показатели чтения и записи в уже существующий файл.
Помимо этого добавим, что часто для случаев необходимости работы с большими количествами файлов оказывается достаточно использования ext4 с заданием нестандартного (увеличенного) количества индексных дескрипторов при разметке диска. Это позволяет в том числе не отказываться от использования журнала, за счёт чего из файловой системы удаётся "выжать максимум" её возможностей.
В заключении дополним, что в ситуациях необходимости размещения огромных количеств маленьких однотипных файлов можно обратиться к разработчику проекта по вопросу пересмотра самого механизма хранения. Если структура содержимого данных файлов постоянна, а максимальный размер известен, вместо них можно использовать базу данных, создав в ней таблицу с соответствующими структуре содержимого указанных файлов столбцами. Это позволит размещать данные фактически в одном основном файле (многие базы данных хранят таблицы в виде пар файлов, один из которых описывает структуру таблицы, а другой хранит её содержимое), а задачи записи и чтения будут переложены на СУБД, на уровне настроек которой их можно оптимизировать. Минусом данного подхода будет необходимость замены функций взаимодействия с файлами на функции взаимодействия с СУБД в скриптах самого сайта. В зависимости от нагрузки от проект такое решение может быть оправдано
