Погані показники NTFS


21

Чому так є продуктивність NTFS настільки хитра у порівнянні, наприклад, з Linux / ext3? Найчастіше я це бачу під час перевірки (великих) дерев-джерел із Subversion. Оформлення замовлення займає близько 10-15 хвилин на NTFS, тоді як відповідна каса в Linux (на майже однаковому обладнанні) займає порядок швидше (1 - 1,5 хвилини).

Можливо, це характерно для обробки безлічі невеликих файлів, і NTFS краще, якщо мова йде про великі файли, але чому це повинно бути? Чи не поліпшення продуктивності NTFS для невеликих файлів вкрай корисно для продуктивності Windows в цілому?

EDIT: Це не означає, що "запальне питання NTFS порівняно з ext3"; Мене щиро цікавить, чому NTFS працює в певних випадках погано. Це просто поганий дизайн (у чому я сумніваюся), чи є інші проблеми, які вступають у гру?


4
Можливо, це можна переробити так, що ви запитуєте, як покращити продуктивність NTFS при роботі з великою кількістю невеликих файлів, а не запитати, чому NTFS відсмоктує порівняно з ext3?
ChrisInEdmonton

Погодьтеся з @Chris, це питання є безглуздим.
Саша Чедигов

4
Ну, мене щиро цікавить, чому NTFS працює погано. Якщо відповідь - "зробіть X, щоб зробити це швидше", тоді чудово, але я б погодився зрозуміти проблему.
JesperE

Ах, гаразд, вибачте за те, що вас не зрозуміли.
Саша Чедигов

2
BTW, коли ви використовували SVN на машині Windows, чи ввімкнено цей апарат для сканування вірусів із захистом у режимі реального часу? Це може бути погано.
dlamblin

Відповіді:


35

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

Ви можете бачити, що ext3 працює добре приблизно до 95% використання диска, тоді як існування MFT означає, що NTFS насправді не хоче, щоб ви використовували більше 90% свого диска. Але я припускаю, що це не ваша проблема, а в тому, що ваша проблема полягає в безлічі операцій над багатьма невеликими файлами.

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

У ext2 і 3, навпаки, блоки файлів для кожного файлу зберігаються поруч, де метадані каталогів для каталогу, в якому вони перебувають (коли можливо, якщо ваш диск нефрагментований і у вас близько 20% вільного місця). Це означає, що, коли svn відкриває каталоги, кілька блоків отримують кешування в основному безкоштовно в тому кеш-пам'яті 16 Мб на вашому диску, а потім знову в кеші ядра. Ці файли можуть включати .svn файл та файли ревізії останнього оновлення. Це зручно, оскільки, ймовірно, деякі з файлів svn переглядають наступний. NTFS цього не робить, хоча великі частини MFT повинні бути кешовані в системі, вони можуть бути не частинами, які ви хочете далі.


2
Ви впевнені, що тут живуть невеликі файли, але я не впевнений, чому це повинно наголосити на MFT. Чи не було б набагато простіше читати ці файли, оскільки ви майже гарантовано перетягуєте багато цих файлів у кеш, коли витягуєте будь-який з них?
ChrisInEdmonton

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

6

Що ж, ваша проблема полягає в тому, що

  1. Сам підрив походить із світу UNIX, тому версія Windows передбачає схожі характеристики продуктивності.
  2. Продуктивність NTFS насправді не велика з газиліонами невеликих файлів.

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

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


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

Бічна примітка: Одночасне оновлення великого сховища SVN, яке я використовую, займало близько 250 000 файлових операцій. Якийсь крихітний голос говорить мені, що це дійсно багато для 24 файлів, які змінилися ...


1
Але чому ефективність NTFS погана при роботі з газільйоном невеликих файлів? Чи потрібно було пожертвувати, щоб отримати щось інше?
JesperE

3

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

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