Файлова система велика кількість файлів в одному каталозі

Гаразд, не настільки великий, але мені потрібно використовувати щось, де в одному каталозі зберігається близько 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, який доступний для 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" дзвінок, а "відкрити + 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-дерева, які набагато ефективніші для великих наборів.

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

Ви не хочете стискати стільки файлів в одному каталозі, вам потрібна якась структура. Навіть якщо це щось таке просте, як наявність підкаталогів, які починаються з першого символу файлу, може покращити ваш час доступу. Ще один нерозумний трюк, який я люблю використовувати, - змусити систему оновлювати кеш-пам’яті з метеаформацією - регулярно запускати оновлення. В одному вікні запустіть панель плит, а в іншому запустіть updateb, і ви побачите, що пам’ять буде виділено на кешування. Це набагато швидше.

Ви не вказали тип даних у цих файлах. Але із звуків цього ви повинні використовувати якусь базу даних з індексуванням для швидкого пошуку.

Файлова система, мабуть, не є ідеальним сховищем для такої вимоги. Якесь сховище баз даних краще. Якщо ви не можете допомогти в цьому, спробуйте розділити файли на кілька каталогів і скористайтеся unionfs, щоб змонтувати (прив’язати) ці каталоги до одного каталогу, де ви хочете, щоб усі файли відображалися. Я взагалі не використовував цю техніку для прискорення, але варто спробувати.