Что Вы используете для тестирования ссылки?
Очень легко насыщать ссылку на 100 Мбит/с и большую часть ссылки на 1 Гбит/с, если Вы просто продвигаете материал из памяти.
При попытке считать материал из диска, и передать другой системе, тем не менее, Вы будете ограничены производительностью диска.
Вот некоторые результаты, сравнивающие весь главный Linux FSes с bonnie ++, что можно использовать в качестве начальной точки.
С точки зрения случайного ищет победы Reiser, сопровождаемые EXT4, сопровождаемым JFS. Я не уверен, будет ли это коррелировать точно к поискам каталога, но кажется, что это был бы индикатор. Необходимо будет сделать собственные тесты для этого конкретно. EXT2 бьет штаны от всего в течение времен создания файла, вероятно, из-за его отсутствия журнала, все еще EXT4 бьет все кроме Reiser, который Вы не можете хотеть использовать из-за текущего статуса hans reiser.
Вы могли бы хотеть изучить диски, которые поддерживают NCQ и удостоверяются, что Ваша установка является установкой для использования его. При тяжелом поиске его должен обеспечить повышение скорости.
Наконец, удостоверьтесь, что Ваша машина имеет тонну поршня. Так как файлы не часто обновляются, Linux закончит тем, что кэшировал большинство из них, чтобы врезаться, если он будет иметь свободное пространство. Если Ваши шаблоны использования будут правильными, то это даст Вам крупное повышение скорости.
Я знаю, что это не прямой ответ на Ваш вопрос, но в этих случаях я думаю, что база данных могла бы более подойти для хостинга этого. Маленькие файлы могут храниться в двоичном формате в таблице базы данных и получаться в wil. Программное обеспечение, которое использует эти файлы, должно смочь поддерживать это хотя...
Я соглашаюсь с большей частью того, что сказал Andrew, за исключением того, что я рекомендую Reiser4 или более старое (но лучше поддерживаемый) ReiserFS. Как те тесты (и документация для ReiserFS) указывают, это разработано для precicesly ситуация, которую Вы спрашиваете о (большие количества небольших файлов или каталогов). Я использовал ReiserFS в прошлом с хинду и Ubuntu без любых проблем.
Относительно состояния Hans Reiser, я не вижу его как являющийся проблемой с кодом или устойчивостью самой Файловой системы. Reiser4 даже спонсируется и DARPA и Linspire поэтому, в то время как я соглашаюсь, что дальнейшее развитие Файловой системы Reiser является неопределенным, я не делаю вещи, которая должна быть решающим фактором относительно того, должен ли кто-либо использовать его или нет.
Я предполагаю ext3 (или ext4), возможно, JFS был бы хорошим решением. Я был бы осторожен с ext4, и btrfs (файловые системы хитры - быть подготовленными с резервными копиями, если Вы хотите использовать последний, новейший материал).
Существуют также различные параметры, которые можно настроить в течение mkfs времени для настройки файловой системы на симпатию.
Я, конечно, рекомендовал бы против XFS. Не потому что это - плохая файловая система, но создание/удаление является дорогостоящей операцией на нем.
Для предотвращения проблем с поисками каталога используйте интеллектуальную схему именования, например:
<first letter of id>_<last letter of id>/<id>
или подобные, более сложные схемы. Это ускорит Ваши поиски каталога и таким образом общие скорости доступа. (Это - старый прием Unix, назад от V7, я думаю),
Большая часть FS будет дросселировать с больше, чем 65K файлами в dir, я думаю, что это все еще верно для ext4. Файловые системы Reiser не имеют того предела (люди по mp3.com заплаченный для проверки в этом). Не уверенный в чем-либо еще, но это - один из сценариев использования, для которых был сделан ReiserFS.
Кто-то из Unix StackExchange создал тест (с исходным кодом) для тестирования только этого сценария:
Похоже, что лучшая производительность чтения обеспечивается ReiserFS.
По моему опыту, ext2 вытесняет ext4 из воды для небольших файлов. Если вас не волнует целостность записи, это здорово. Например, subversion создает много-много-много маленьких файлов, которые блокируют ext4 и другие файловые системы (XFS) (запускает задание cron, которое синхронизирует данные с ext4 на ext2 каждые полчаса или около того, что практически решает проблему)
. ] Выполнение этих команд делает ext2 еще быстрее (даже несмотря на то, что большинство из этих параметров делают файловую систему нестабильной после сбоя, если вы не запустите синхронизацию до сбоя). Эти команды почти не влияют на ext4 с небольшими файлами.
echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure