Скільки файлів можна помістити в каталог?


561

Чи має значення, скільки файлів я зберігаю в одному каталозі? Якщо так, то скільки файлів у каталозі занадто багато, і які наслідки має занадто багато файлів? (Це на сервері Linux.)

Передумови: у мене є веб-сайт з фотоальбомом, і кожне завантажене зображення перейменовано на 8-значний ідентифікатор (скажімо, a58f375c.jpg). Це дозволяє уникнути конфліктів імен файлів (якщо, наприклад, завантажено багато файлів "IMG0001.JPG"). Оригінальне ім'я файлу та будь-які корисні метадані зберігаються у базі даних. Зараз у мене в каталозі зображень є десь близько 1500 файлів. Це робить перелік файлів у каталозі (через FTP або SSH-клієнт) зайняти кілька секунд. Але я не бачу, що це має якийсь інший ефект, крім цього. Зокрема, не здається, що це вплине на те, як швидко файл зображення подається користувачеві.

Я думав про зменшення кількості зображень, створивши 16 підкаталогів: 0-9 та af. Тоді я переміщу зображення в підкаталоги, виходячи з того, що було першою шістнадцятковою цифрою імені файлу. Але я не впевнений, що для цього є якісь причини, крім випадкового перерахування каталогу через FTP / SSH.

Відповіді:


736

FAT32 :

  • Максимальна кількість файлів: 268 173 300
  • Максимальна кількість файлів у каталозі: 2 16  - 1 (65,535)
  • Максимальний розмір файлу: 2 GiB - 1 без LFS , 4 GiB - 1 с

NTFS :

  • Максимальна кількість файлів: 2 32  - 1 (4,294,967,295)
  • Максимальний розмір файлу
    • Реалізація: 2 44  - 2 6 байт (16 TiB - 64 KiB)
    • Теоретично: 2 64  - 2 6 байт (16 EiB - 64 KiB)
  • Максимальний розмір гучності
    • Реалізація: 2 32  - 1 кластери (256 TiB - 64 KiB)
    • Теоретично: 2 64  - 1 кластер (1 YiB - 64 KiB)

ext2 :

  • Максимальна кількість файлів: 10 18
  • Максимальна кількість файлів у каталозі: ~ 1,3 × 10 20 (проблеми з продуктивністю за останні 10 000)
  • Максимальний розмір файлу
    • 16 GiB (розмір блоку 1 KiB)
    • 256 Гб (розмір блоку 2 Кб)
    • 2 TiB (розмір блоку 4 KiB)
    • 2 TiB (розмір блоку 8 KiB)
  • Максимальний розмір гучності
    • 4 TiB (розмір блоку 1 KiB)
    • 8 TiB (розмір блоку 2 KiB)
    • 16 TiB (розмір блоку 4 KiB)
    • 32 TiB (розмір блоку 8 KiB)

ext3 :

  • Максимальна кількість файлів: хв (об'ємна величина / 2 13 , кількістьOfBlocks)
  • Максимальний розмір файлу: такий же, як ext2
  • Максимальний розмір гучності: такий же, як ext2

ext4 :

  • Максимальна кількість файлів: 2 32  - 1 (4,294,967,295)
  • Максимальна кількість файлів у каталозі: необмежена
  • Максимальний розмір файлу: 2 44  - 1 байт (16 TiB - 1)
  • Максимальний розмір гучності: 2 48  - 1 байт (256 TiB - 1)

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

19
Оскільки ми зараз у 2012 році, я думаю, що настав час зрозуміти, що ext4 не має жодних обмежень щодо кількості підкаталогів. Також максимальний розмір файлів виріс до 16 ТБ. Крім того, загальний розмір файлової системи може становити до 1 ЕВ = 1,048,576 ТБ.
devsnd

7
Мабуть, ext3 також має обмеження в 60000 файлів (або каталогів або посилань) на каталог. Я дізнався важкий шлях про це.
stackular

8
Старий відповідь, я знаю ... але коли ви пишете EXT4 - Максимальна кількість файлів: 2³² - 1 (4,294,967,295) та Максимальна кількість файлів у каталозі: необмежена, ви нас справді збентежили, оскільки 2³² - 1! = "Необмежений". Я думаю, мені зараз потрібна кава. ;) Тим не менше +1
e-sushi

10
Обмеження жорсткої файлової системи не відповідають на питання " Чи має значення, скільки файлів я зберігаю в одному каталозі? "
Etki

191

У мене було понад 8 мільйонів файлів в одному каталозі ext3. libc, readdir()який використовується find, lsі більшість інших методів, обговорених у цій темі, для переліку великих каталогів.

Причина lsта findповільність у цьому випадку полягає в тому, що readdir()одночасно читає лише 32K записів каталогів, тому на повільних дисках для переліку каталогу буде потрібно багато читання. Вирішення цієї проблеми швидкості є. Я написав досить детальну статтю про це за адресою: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- л /

Ключовий винос: використання getdents()безпосередньо - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html, а не все, що засноване на libc, readdir()щоб ви могли вказати буфер розмір при читанні записів каталогів з диска.


6
Цікаво читайте! Чи можу я запитати, в якій ситуації у вас було 8 мільйонів файлів в одному каталозі? ха-ха
1616

У мене було те саме. Я перемістив стовпчик блоку таблиці, кожен стовпець блоку, який я експортував як файл. Це близько 8 мільйонів файлів :)
Спайк

65

У мене каталог з 88 914 файлами в ньому. Як і ви, це використовується для зберігання мініатюр та на сервері Linux.

Перелічені файли через FTP або функцію php повільно, але також існує показник продуктивності відображення файлу. наприклад, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg час очікування - 200-400 мс. Для порівняння на іншому сайті, в якому я маю близько 100 файлів у каталозі, зображення відображається лише через 40 хвилин очікування.

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


6
Це єдина корисна відповідь. Ми зробили подібний досвід. Наш ліміт - 1.000 файлів, щоб зменшити проблеми з резервними копіями (занадто багато каталогів також сповільнюються).
mgutt

1
Також може бути корисно встановити накопичувач у режимі noatime: howtoforge.com/… та прочитати це також: serverfault.com/questions/354017/…
mgutt

2
Яку файлову систему ви використовуєте там, де вона настільки сповільнюється? Наприклад, XFS повинен мати можливість легко обробляти 100 000 файлів у каталозі без помітного уповільнення.
Етан

1
Суперечать думці більшості інших, я хочу підтвердити цю відповідь. На нашому веб-сайті в соціальній мережі є сотні тисяч зображень. Для підвищення продуктивності ми були змушені мати 100 (або 1000 для деяких файлів) підкаталогів і розподіляти файли в них (ext3 на linux + Apache для нас).
wmac

57

Це трохи залежить від конкретної файлової системи, яка використовується на сервері Linux. На сьогоднішній день за замовчуванням є ext3 з dir_index, що робить пошук великих каталогів дуже швидким.

Тому швидкість не повинна бути проблемою, крім тієї, яку ви вже відзначили, а це те, що списки займуть більше часу.

Існує обмеження на загальну кількість файлів в одному каталозі. Я, мабуть, пам’ятаю, що це точно працювало до 32000 файлів.


4
Gnome та KDE завантажують великі каталоги зі швидкістю равликів, вікна кешуватимуть каталог так, що його розумно. Я люблю Linux, але kde та gnome написані погано.
грак

1
І ext4, схоже, за замовчуванням має еквівалент dir_index.
Контракт професора Фолкена порушив

22
В одній директорії в ext3 є обмеження приблизно на 32K підкаталогів , але ОП говорить про файли зображень. Немає (практичного?) Обмеження для файлів у файловій системі ext3 з включеним Dir Index.
Пітер Н Льюїс

1
Ця відповідь застаріла, сьогодні за замовчуванням є ext4 .
Борис

1
"Немає (практичного?) Обмеження для файлів у файловій системі ext3 з увімкненою функцією Dir Index" - у мене просто не вистачало файлового простору в каталозі файлової системи 44B ext4, з dir_indexувімкненою функцією. У мене було близько 17 мільйонів файлів у каталозі. Відповідь полягала в тому, щоб увімкнути large_dirtune2fs.
lunixbochs

49

Майте на увазі, що в Linux, якщо у вас є каталог із занадто великою кількістю файлів, оболонка може не змогти розширювати підстановки. У мене ця проблема з фотоальбомом, розміщеним в Linux. Він зберігає всі розміри зображень в одному каталозі. Хоча файлова система може обробляти багато файлів, оболонка не може. Приклад:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

або

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve, використовуйте find (1) та / або xargs (1) для цих випадків. З цієї ж причини непогано використовувати такі інструменти в скриптах замість розширення командного рядка.
Дейв C

3
@Steve Ви бачите продуктивність, коли кількість файлів у папці збільшується? Або стосунків немає?
Печер'є

6
Це хороший момент, але, по відношенню до ниткоподібних, причина неправильна. Спісок_аргументи занадто довго це обмеження не оболонок, але система execреалізації. Оболонка зазвичай може просто розширити підстановку - це заклик до execтакої кількості аргументів, що повертає помилку.
jw013

У мене була та сама помилка вчора ввечері (Fedora 15) із "rm" (somefiles *) з приблизно ~ 400 000 файлів у каталозі. Мені вдалося обрізати старіші файли з "find" до того моменту, коли я міг "rm" за допомогою магістра.
PJ Brunet

10 000 000 файлів у каталог на etx4 працює чудово. Не так сильно вдарив про продуктивність під час доступу. Але досить повільно з wildcard. Будьте обережні, використовуючи програми оболонки, які люблять сортувати назви файлів! :)
Simon Rigét

25

Я зараз працюю над подібною проблемою. Ми маємо ієрархічну структуру каталогів і використовуємо ідентифікатори зображень як імена файлів. Наприклад, зображення id=1234567, розміщене в

..../45/67/1234567_<...>.jpg

використовуючи останні 4 цифри, щоб визначити, куди йде файл.

Маючи кілька тисяч зображень, ви можете використовувати однорівневу ієрархію. Наш системний адміністратор запропонував не більше ніж кілька тисяч файлів у будь-якому каталозі (ext3) для ефективності / резервного копіювання / з будь-яких інших причин, які він мав на увазі.


1
Це досить приємне рішення. Кожен рівень вашого каталогу до файлу мав би не більше 100 записів у ньому, якщо ви дотримуєтесь двозначної розбивки, а в нижній частині самого каталогу буде лише 1 файл.
RobKohr

Реалізація PHP: stackoverflow.com/a/29707920/318765
mgutt

21

Що для цього варто, я просто створив каталог у ext4файловій системі з 1 000 000 файлів у ньому, а потім випадковим чином отримав доступ до цих файлів через веб-сервер. Я не помітив жодної премії за доступ до тих, хто старший (скажімо), маючи там лише 10 файлів.

Це кардинально відрізняється від мого досвіду цього ntfsкілька років тому.


які файли? текст або зображення? Я на ext4 і мені доведеться імпортувати 80000 зображень в єдиний каталог під wordpress і хотів би знати, чи буде це добре
Івон Хуйнх

1
@YvonHuynh: Тип файлу абсолютно не має значення. Накладні витрати в каталозі списку / відстеження файлу однакові незалежно.
TJ Crowder

14

Найбільша проблема, з якою я стикався, стосується 32-бітної системи. Після проходження певної кількості такі інструменти, як "ls", перестають працювати.

Спроба зробити що-небудь із цим каталогом, як тільки ви пройдете цей бар'єр, стає величезною проблемою.


9

У мене було те саме питання. Спроба зберігати мільйони файлів на сервері Ubuntu в ext4. Закінчила показ власних орієнтирів. З'ясували, що плоский каталог працює набагато краще, при цьому простіший у використанні:

орієнтир

Написав статтю .


Посилання на рішення вітається, але будь-ласка, переконайтеся, що ваша відповідь корисна без неї: додайте контекст навколо посилання, щоб ваші колеги користувачі мали уявлення про те, що це таке і чому воно є, а потім наведіть найбільш релевантну частину сторінки, яку ви " повторне посилання на те, якщо цільова сторінка недоступна. Відповіді, які є трохи більше ніж посилання, можуть бути видалені.
Самуель Liew

1
Цікаво. Ми з'ясували, що навіть після 10 000 файлів продуктивність знизилася дуже швидко, аж до непридатності. Ми вирішили розбивати файли на підкаталоги близько 100 на кожному рівні, щоб досягти оптимальної продуктивності. Я думаю, що мораль цієї історії полягає у тому, щоб завжди орієнтувати її на своїх власних системах із власними вимогами.
Джошуа Пінтер

7

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

Наприклад, F-Spot зберігає файли фотографій як YYYY \ MM \ DD \ filename.ext, що означає, що найбільший каталог, з яким мені довелося мати справу, вручну маніпулюючи колекцією ~ 20000 фотографій, - це близько 800 файлів. Це також робить файли легшими для пошуку в сторонній програмі. Ніколи не вважайте, що ваше програмне забезпечення - це єдине, що матиме доступ до файлів програмного забезпечення.


6
Я рекламую проти розподілу за датою, оскільки масовий імпорт може кластерувати файли на певну дату.
макс

Хороший момент. Ви обов'язково повинні розглянути випадки використання, перш ніж вибрати схему розподілу. Мені трапляється імпортувати фотографії протягом багатьох днів у досить широкому розповсюдженні, І коли я хочу маніпулювати фотографіями поза датою F-Spot, це найпростіший спосіб їх знайти, тому для мене це подвійний виграш.
Спарр

7

Це абсолютно залежить від файлової системи. Багато сучасних файлових систем використовують пристойні структури даних для зберігання вмісту каталогів, але старі файлові системи часто просто додавали записи до списку, тому отримання файлу була операцією O (n).

Навіть якщо файлова система робить це правильно, програми, які перераховують вміст каталогів, все-таки є абсолютно можливим, щоб зіпсувати і зробити сортування O (n ^ 2), щоб бути в безпечній частині, я завжди обмежував би кількість файлів на каталог не більше 500.


7

Це дійсно залежить від використовуваної файлової системи, а також деяких прапорів.

Наприклад, ext3 може мати багато тисяч файлів; але через пару тисяч це було дуже повільно. Переважно при переліку каталогу, але також при відкритті одного файлу. Кілька років тому він отримав опцію 'htree', яка значно скоротила час, необхідний для отримання inode з назвою файлу.

Особисто я використовую підкаталоги, щоб підтримувати більшість рівнів під тисячу елементів. У вашому випадку я створив би 256 каталогів з двома останніми шістнадцятковими цифрами ідентифікатора. Використовуйте останню та не першу цифри, щоб ви збалансували навантаження.


6
Якби назви файлів були абсолютно випадковими, не має значення, які цифри використовувалися.
страгер

Дійсно, ці назви файлів генеруються випадковим чином.
Кіп

2
Або скористайтеся першими N байтами дайджеста SHA-1 імені файлу.
gawi

6

Фактично у ext3 є обмеження розміру каталогів, і вони залежать від розміру блоку файлової системи. Існує не "Максимальна кількість" файлів у каталозі, а "Максимальна кількість блоків, що використовуються для зберігання записів файлів". Зокрема, розмір самого каталогу не може перевищувати b-дерево висоти 3, а розмір дерева залежить від розміру блоку. Дивіться це посилання для отримання детальної інформації.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Мене це нещодавно покусало у файловій системі, відформатованій 2K-блоками, яка незрозуміло отримувала повідомлення ядра з повним каталогом, warning: ext3_dx_add_entry: Directory index full!коли я копіював з іншої файлової системи ext3. У моєму випадку каталог із просто 480 000 файлів не вдалося скопіювати до місця призначення.


5

Питання зводиться до того, що ви збираєтеся робити з файлами.

У Windows будь-який каталог із більш ніж 2 к файлами, як правило, повільно відкривається для мене в Провіднику. Якщо вони всі файли зображень, більше 1 кк, як правило, відкривається дуже повільно у вигляді мініатюр.

Свого часу встановлений системою ліміт становив 32 767. Зараз це вище, але навіть у більшості обставин одночасно обробляється занадто багато файлів.


5

Що більшість відповідей, наведених вище, не показує, це те, що немає відповіді "Один розмір, який відповідає всім" на початкове запитання.

У сучасних умовах у нас є великий конгломерат різного обладнання та програмного забезпечення - дехто - 32 біт, хтось - 64 біт, хтось є передовим, а хтось випробуваний і справжній - надійний і ніколи не змінюється. До цього додається різноманітне старі та новіші апаратні засоби, старіші та новіші ОС, різні постачальники (Windows, Unixes, Apple тощо) та безліч утиліт та серверів, які йдуть разом. Оскільки обладнання покращилось, а програмне забезпечення перетворилося на 64-бітну сумісність, обов'язково була значна затримка в тому, щоб усі частини цього дуже великого і складного світу чудово грати зі швидкими темпами змін.

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

У мене, наприклад, є медіа-сервер з кількома дуже великими файлами. Результат - лише близько 400 файлів, що заповнюють накопичувач на 3 ТБ. Використовується лише 1% утворень, але використовується 95% всього простору. У когось іншого, з великою кількістю менших файлів може не вистачати вкладки, перш ніж вони наблизяться до заповнення місця. (У файлових системах ext4, як правило, для кожного файлу / каталогу використовується 1 inode.) Хоча теоретично загальна кількість файлів, які можуть міститися в каталозі, майже нескінченна, практичність визначає, що загальне використання визначає реалістичні одиниці, а не просто можливості файлової системи.

Я сподіваюсь, що всі різні відповіді, наведені вище, сприяли роздумуванню та вирішенню проблем, а не створювали непереборний бар'єр для прогресу.


4

Я пригадую запуск програми, яка створювала величезну кількість файлів на виході. Файли були відсортовані за 30000 за каталогом. Я не пам'ятаю, щоб були проблеми з читанням, коли мені довелося повторно використовувати отриманий результат. Це було на 32-бітному ноутбуці Ubuntu Linux, і навіть Nautilus відображав вміст каталогів, хоча і через кілька секунд.

файлова система ext3: Подібний код у 64-бітній системі добре справляється з 64000 файлами в каталозі.


4

"Залежить від файлової системи"
Деякі користувачі зазначили, що ефективність роботи залежить від використовуваної файлової системи. Звичайно. Такі файлові системи, як EXT3, можуть бути дуже повільними. Але навіть якщо ви використовуєте EXT4 або XFS ви не можете запобігти , що лістинг папки через lsабо findабо через зовнішнє з'єднання , як FTP буде повільніше повільніше.

Рішення
я віддаю перевагу так само, як @armandino . Для цього я використовую цю маленьку функцію в PHP для перетворення ідентифікаторів у файловий шлях, що призводить до 1000 файлів у каталозі:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

або ви можете використовувати другу версію, якщо хочете використовувати буквено-цифрові символи:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

результати:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Як ви бачите для $int-версії, кожна папка містить до 1000 файлів і до 99 каталогів, що містять 1000 файлів і 99 каталогів ...

Але не забувайте, що для багатьох каталогів виникають однакові проблеми з роботою!

Нарешті, слід подумати про те, як зменшити загальну кількість файлів. Залежно від цілі ви можете використовувати CSS-спрайти для комбінування декількох крихітних зображень, таких як аватари, піктограми, посмішки тощо, або якщо ви використовуєте багато невеликих немедіа-файлів, розглядайте можливість їх поєднання, наприклад, у форматі JSON. У моєму випадку у мене було тисячі міні-кешів і, нарешті, я вирішив об'єднати їх у 10 пачок.


3

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


3

Я зіткнувся з подібним питанням. Я намагався отримати доступ до каталогу із понад 10 000 файлів у ньому. Створення списку файлів та виконання команд будь-якого типу на будь-якому з файлів зайняло занадто багато часу.

Я придумав невеликий скрипт для php, щоб зробити це для себе, і спробував розкрити спосіб запобігти його тимчасовому відключенню в браузері.

Далі йде сценарій php, який я написав для вирішення проблеми.

Список файлів у каталозі із занадто великою кількістю файлів для FTP

Як це комусь допомагає


1

Не відповідь, а лише деякі пропозиції.

Виберіть більш підходящий FS (файлова система). Оскільки, з історичної точки зору, всі ваші питання були достатньо мудрими, щоб колись бути центральним для ФС, що розвиваються протягом десятиліть. Я маю на увазі, що більш сучасні ФС краще підтримують ваші проблеми. Спочатку складіть таблицю рішень порівняння на основі вашої кінцевої мети зі списку FS .

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

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

Для подолання лімітів обладнання ви можете використовувати RAID-0.


1

Не існує жодної цифри, яка "занадто велика", доки вона не перевищує межі ОС. Однак чим більше файлів у каталозі, незалежно від ОС, тим довше потрібно отримати доступ до будь-якого окремого файлу, а для більшості ОС ефективність нелінійна, тому пошук одного файлу з 10000 займає більше ніж у 10 разів довше потім знайти файл в 1000.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.