Продуктивність NTFS та великий об'єм файлів і каталогів

Як Windows з NTFS працює з великими обсягами файлів і каталогів?

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

Наприклад, мати папку зі 100 000 папок всередині неї нормально?

Ось кілька порад від когось із оточення, де у нас є папки, що містять десятки мільйонів файлів.

1. Папка зберігає інформацію про індекс (посилання на дочірні файли та дочірню папку) у індексний файл. Цей файл вийде дуже великим, коли у вас багато дітей. Зауважте, що він не розрізняє дитину, яка є папкою, і дитину, яка є файлом. Єдина відмінність полягає лише в тому, що вміст цієї дитини - це або індекс папки дитини, або дані файлу дитини. Примітка: я дещо спрощую це, але це стає зрозумілим.
2. Файл індексу буде фрагментованим. Коли він буде занадто фрагментарним, ви не зможете додати файли до цієї папки. Це пов’язано з тим, що існує обмеження на кількість дозволених фрагментів. Це за дизайном. Я підтвердив це в Microsoft при виклику служби підтримки. Тож хоча теоретичний ліміт кількості файлів, які ви можете мати у папці, становить декілька мільярдів, удача, коли ви почнете потрапляти на десятки мільйонів файлів, оскільки ви спочатку натиснете на обмеження фрагментації.
3. Однак це не все погано. Ви можете використовувати інструмент: contig.exe для дефрагментації цього індексу. Це не зменшить розмір індексу (який може досягати декількох гігів для десятків мільйонів файлів), але ви можете зменшити кількість фрагментів. Примітка: Інструмент Дефрагментації диска НЕ ​​буде дефрагментувати індекс папки. Це дефрагментує файлові дані. Тільки інструмент contig.exe дефрагментує індекс. FYI: Ви також можете використовувати це для дефрагментації даних окремого файлу.
4. Якщо ви зробите дефрагментацію, не чекайте, поки ви не досягнете максимальної # межі фрагмента. У мене є папка, в якій я не можу дефрагментуватись, тому що я зачекав, поки не пізно. Наступним моїм тестом є спробувати перемістити деякі файли з цієї папки в іншу папку, щоб побачити, чи зможу я її дефрагментувати. Якщо цього не вдасться, то я мав би зробити це 1) створити нову папку. 2) перемістити партію файлів у нову папку. 3) дефрагментуйте нову папку. повторюйте №2 та №3, доки цього не буде зроблено, а потім 4) видаліть стару папку та перейменуйте нову папку відповідно до старої.

Щоб відповісти на запитання більш прямо: Якщо ви переглядаєте записи на 100 К, не хвилюйтесь. Іди вибивати себе. Якщо ви переглядаєте десятки мільйонів записів, то будь-яке:

а) Складайте плани поділити їх на підпапки (наприклад, скажімо, що у вас є 100М файлів. Краще зберігати їх у 1000 папках, щоб у вас було лише 100 000 файлів у папці, ніж зберігати їх у 1 великій папці. Це створить 1000 індексів папок замість одного великого, який, швидше за все, перевищить максимальну кількість меж фрагментів або

b) Плануйте регулярно запускати contig.exe, щоб індекс вашої великої папки був дефрагментованим.

Читайте нижче, лише якщо вам нудно.

Фактична межа не на число фрагмента, а на кількість записів сегменту даних, що зберігає вказівники на фрагмент.

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

Існують також проблеми з продуктивністю створення короткого імені файлів, що сповільнює роботу. Корпорація Майкрософт рекомендує вимкнути створення короткого імені файлу, якщо у вас є більше 300 К файлів у папці [1]. Чим менш унікальні перші 6 символів, тим більше в цьому проблеми.

[1] Як працює NTFS від http://technet.microsoft.com , шукайте "300 000"

Я будую файлову структуру для розміщення до 2 мільярдів (2 ^ 32) файлів і виконую наступні тести, які показують різке падіння продуктивності навігації + читання приблизно на 250 файлів або 120 каталогів у каталозі NTFS на твердотільному диску ( SSD):

• Ефективність файлів падає на 50% від 250 до 1000 файлів.
• Ефективність каталогу знижується на 60% між 120 та 1000 каталогіми.
• Значення для чисел> 1000 залишаються відносно стабільними

Цікаво, що кількість каталогів та файлів НЕ суттєво заважає.

Отже, уроки:

• Номери файлів вище 250 коштують коефіцієнт 2
• Довідники вище 120 коштують коефіцієнта 2,5
• File-Explorer у Windows 7 може працювати з великими #Files або #Dirs, але юзабіліті все ще погані.
• Представлення підкаталогів недешеве

Це Дані (2 вимірювання для кожного файлу та каталогу):

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

А це тестовий код:

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}

100 000 має бути добре.

Я (анекдотично) бачив людей, які мали проблеми з багатьма мільйонами файлів, і у мене були проблеми з Провідником, просто не маючи підказки, як підрахувати минулі 60-тисячі файлів, але NTFS повинен бути хорошим для тих обсягів, про які ви говорите.

У випадку, якщо вам цікаво, максимальна технічна (і я сподіваюся теоретична ) максимальна кількість файлів: 4,294,967,295

Для локального доступу велика кількість каталогів / файлів, здається, не є проблемою. Однак, якщо ви отримуєте доступ до нього через мережу, помітний показник продуктивності після декількох сотень (особливо при доступі з машин Vista (XP на Windows Server w / NTFS, здавалося, працює в цьому відношенні набагато швидше)).

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

Для сценаріїв лише для читання я не можу уявити жодної причини для зниження продуктивності каталогів з великою кількістю записів.

Я мав реальний досвід роботи з близько 100 000 файлів (кожен по кілька МБ) на NTFS в каталозі під час копіювання однієї інтернет-бібліотеки.

На відкриття каталогу за допомогою Explorer або 7-zip потрібно близько 15 хвилин.

Написання копії сайту winhttrackзавжди застрягне через деякий час. Він також стосувався каталогу, що містить близько 1 000 000 файлів. Я думаю, що найгірше те, що MFT може пройти лише послідовно.

Відкриття ж під ext2fsd на ext3 дало майже однакові терміни. Можливо, перехід до reiserfs (не reiser4fs) може допомогти.

Намагатися уникати такої ситуації, мабуть, найкраще.

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