Файловая система большого количества файлов в одном каталоге

Хорошо, не такой большой, но мне нужно использовать что-то, где около 60 000 файлов со средним размером 30 КБ хранятся в одном каталоге (это требование, поэтому нельзя просто разбить его на подкаталоги с меньшим количеством файлов).

Доступ к файлам будет осуществляться случайным образом, но после создания не будет никаких записей в одну и ту же файловую систему. Я в настоящее время использую Ext3, но нахожу это очень медленно. Какие-либо предложения?

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

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

Один миллиард файлов в Linux

Автор этой статьи рассматривает некоторые проблемы с производительностью файловых систем с большим количеством файлов и делает несколько хороших сравнений производительности различных файловых систем ext3, ext4 и XFS. Это доступно в виде слайд-шоу. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

Многие файлы в каталоге на ext3 подробно обсуждались на дочернем сайте stackoverflow.com

На мой взгляд, 60 000 файлов в одной директории на ext3 далеко не идеальны, но в зависимости от ваших других требований это может быть достаточно хорошим

ХОРОШО. Я провел предварительное тестирование с использованием ReiserFS, XFS, JFS, Ext3 (dir_hash включен) и Ext4dev (ядро 2.6.26). Моим первым впечатлением было то, что все было достаточно быстро (на моей мощной рабочей станции) - оказалось, что на удаленной рабочей машине довольно медленный процессор.

Я испытывал некоторые странности с ReiserFS даже при первоначальном тестировании, поэтому исключил это. Кажется, что JFS требует на 33% меньше ресурсов процессора, чем все остальные, и поэтому проверит это на удаленном сервере. Если он будет работать достаточно хорошо, я воспользуюсь этим.

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

ext3 медленный в основном из-за реализации по умолчанию «связанного списка». Так что если у вас есть много файлов в одном каталоге, это означает, что открытие или создание другого будет становиться все медленнее и медленнее. Есть нечто, называемое htree index, доступное для ext3, которое, как сообщается, значительно улучшает ситуацию. Но это доступно только при создании файловой системы. Глянь сюда: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Поскольку вам все равно придется перестраивать файловую систему и из-за ограничений ext3, я рекомендую вам взглянуть на использование ext4 (или XFS). Я думаю, что ext4 немного быстрее с небольшими файлами и быстрее перестраивает. Насколько мне известно, индекс htree по умолчанию для ext4. У меня нет опыта работы с JFS или Reiser, но я слышал, что люди рекомендуют это раньше.

В действительности, я бы, наверное, протестировал несколько файловых систем. Почему бы не попробовать ext4, xfs & jfs и посмотреть, какой из них дает наилучшую общую производительность?

То, что разработчик сказал мне, что может ускорить процесс в коде приложения, это не вызов «stat + open», а «open + fstat». Первый значительно медленнее второго. Не уверен, если у вас есть контроль или влияние на это.

Смотрите мой пост здесь на stackoverflow. Храня и получая доступ к 10 миллионам файлов в Linux, здесь есть несколько очень полезных ответов и ссылок.

Использование tune2fs для включения dir_index может помочь. Чтобы увидеть, включен ли он:

sudo tune2fs -l /dev/sda1 | grep dir_index

Если он не включен:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

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

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

Кроме того, способ хранения каталогов в файловых системах ext *, по сути, представляет собой один большой список. В более современных файловых системах (Reiser, XFS, JFS) они хранятся в виде B-деревьев, которые намного эффективнее для больших наборов.

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

Вы не хотите втиснуть столько файлов в один каталог, вам нужна какая-то структура. Даже если это так просто, как наличие подкаталогов, которые начинаются с первого символа файла, это может сократить время доступа. Другой глупый трюк, который мне нравится использовать, - заставить систему обновлять свой кеш с помощью метаинформации - регулярно запускать updatedb. В одном окне запустите slabtop, а в другом запустите updatedb, и вы увидите, что много памяти будет выделено для кэширования. Так намного быстрее.

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

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