максимум файлів у каталозі в ext4

Я керую програмою, що містить магазин файлів, у якому всі файли зберігаються з іменами файлів, рівними їх сум md5. Усі файли зберігаються в одному каталозі. Наразі їх тисячі, але незабаром їх повинно бути мільйони файлів на сервері. На поточному сервері працює Ubuntu 11.10 у файловій системі ext4.

Хтось сказав мені, що не доцільно поміщати багато файлів у каталог, оскільки це призведе до значного збільшення часу пошуку та надійності (у нього була історія про максимум файлів, на які міг би вказати один dir, що призведе до великого пов'язаного списку). Натомість він запропонував створити підкаталоги з, наприклад, підрядками імені файлу. Однак це зробить деякі речі в моїй заявці набагато громіздкішими.

Це все-таки правда, чи сучасні файлові системи (наприклад, ext4) мають більш ефективні способи боротьби з цим і, природно, масштабами? У Вікіпедії є деякі деталі щодо файлових систем, але вона насправді нічого не говорить про максимум файлів у каталозі чи час пошуку.

Більш ext3пізні файлові системи підтримують хешоване індексування каталогів B-tree . Це масштабується дуже добре, якщо єдині операції, які ви виконуєте, - це додавання, видалення та доступ до імені. Однак я все-таки рекомендую зруйнувати каталоги. В іншому випадку, ви створюєте небезпечну пастку для інструментів ( updatedb, ls, duі так далі) , які виконують інші операції над каталогами , які можуть підірвати , якщо каталог має занадто багато записів.

Основною проблемою є перекодування в каталозі inode одного файлу, який ви хочете. Деякі файлові системи роблять це краще, ніж інші. Деякі масштаби наближаються до мільярдів, але якщо у вас є лише ... 20K файлів, що потрапляють до цих файлів помітно швидше. Крім того, велика кількість файлів створює проблеми для певних інструментів і може зробити резервне копіювання / відновлення набагато складнішою проблемою.

Як це буває, я зіткнувся з точно такою ж проблемою у власній розробці (md5sum як ім'я файлу, його масштабування). Те, що я рекомендував нашим розробникам, - це нарізати рядок на шматки. Вони пішли з групами по 4, але у файловій системі ми були в той час навіть, що багато хто виявиться проблематичним з точки зору продуктивності, тому вони закінчилися розбиватися на групу-3 для перших 6 трійків, а решту залишили як ім'я файлу в каталозі терміналів.

Група 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
3 група:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Це має перевагу в тому, щоб розмір каталогів був невеликим, а оскільки MD5sum досить випадковий, він створить збалансовані дерева каталогів. Цей останній каталог навряд чи зможе отримати більше кількох файлів. І чи не так складно було б працювати над нашим кодом. Ми працюємо з багатомільйонними файловими проектами, тому масштабування було для нас дуже важливим.

Сучасні файлові системи дуже добре обробляють великі каталоги, навіть мільйони файлів. Але звичайні засоби - ні. Наприклад, перерахування такого великого каталогу з "ls" займе досить багато часу, оскільки воно, як правило, читає весь каталог і сортує його (хоча ви можете використовувати ls -f, щоб уникнути сортування). Файли не почати показувати файли, поки всі не будуть прочитані. Розщеплення імен допомагає в деяких випадках, але не у всіх (наприклад, для реплікації rsync все-таки може знадобитися зібрати все дерево імен).

Чи можу я замість цього запропонувати використовувати базу даних SQL? Це, ймовірно, перетворить цю сприйняту слабкість у вашому застосуванні в силу.