Плохая производительность NTFS

7711
JesperE

Почему производительность NTFS такая отвратительная по сравнению, например, с Linux / ext3? Чаще всего я вижу это при проверке (больших) исходных деревьев из Subversion. Оформление заказа занимает около 10-15 минут в NTFS, в то время как соответствующая проверка в Linux (на почти идентичном оборудовании) занимает на порядок быстрее (1 - 1,5 минуты).

Может быть, это специфично для обработки большого количества маленьких файлов, и NTFS лучше, когда речь идет о больших файлах, но почему это должно быть? Разве повышение производительности NTFS для небольших файлов не будет чрезвычайно полезным для производительности Windows в целом?

РЕДАКТИРОВАТЬ: Это не означает, что "NTFS отстой по сравнению с ext3" подстрекательский вопрос; Меня искренне интересует, почему NTFS работает плохо в определенных случаях. Это просто плохой дизайн (в чем я сомневаюсь), или есть другие проблемы, которые вступают в игру?

20
Возможно, это можно перефразировать так, что вы спрашиваете, как улучшить производительность NTFS при работе с большим количеством маленьких файлов, а не спрашиваете, почему NTFS отстой по сравнению с ext3? ChrisInEdmonton 14 лет назад 4
Согласитесь с @Chris, этот вопрос как бы бессмыслен. Sasha Chedygov 14 лет назад 0
Что ж, меня искренне интересует, почему NTFS работает плохо. Если ответ «сделай X, чтобы сделать это быстрее», то отлично, но я бы согласился на понимание проблемы. JesperE 14 лет назад 3
Ах, хорошо, извините за недопонимание вас. Sasha Chedygov 14 лет назад 0
Кстати, когда вы использовали SVN на компьютере с Windows, был ли на этом компьютере антивирусный сканер с включенной защитой в реальном времени? Это может быть плохо. dlamblin 14 лет назад 2
Я протестировал оба способа, и хотя антивирусный сканер оказал ощутимое влияние, он не объяснил плохую производительность NTFS. JesperE 14 лет назад 0
в некоторых случаях, возможно, exFAT лучше, потому что он не имеет многих громоздких функций NTFS, таких как разрешение, сжатие и т. д. phuclv 10 лет назад 0

3 ответа на вопрос

34
dlamblin

NTFS имеет эту вещь, называемую Master File Table . Это звучит очень круто, когда вы читаете об этом.

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

Одно из отличий заключается в том, что происходит, когда вы создаете небольшой файл. Если файл меньше размера блока, он не записывается в собственный блок, а сохраняется в MFT. Это хорошо, если файл остается точно таким же, каким он был при создании. Однако на практике это означает, что когда svn касается файла, чтобы создать его, затем добавляет к этому файлу, удаляет из него или просто модифицирует его, когда его недостаточно для перемещения в собственный блок, операция выполняется довольно медленно. Также простое чтение большого количества маленьких файлов создает некоторую нагрузку на MFT, где они все находятся, с кратными на блок. Зачем это делать? Это упреждающий отказ от фрагментации и более эффективное использование большего количества блоков, и в целом это хорошо.

В ext2 и 3, напротив, файловые блоки для каждого файла хранятся рядом с тем местом, где находятся метаданные каталога для каталога, в котором они находятся (когда это возможно, если ваш диск нефрагментирован и у вас есть около 20% свободного места). Это означает, что когда svn открывает каталоги, ряд блоков кешируется в основном бесплатно в этом 16-мегабайтном кеше на вашем диске, а затем снова в кеш-памяти ядра. Эти файлы могут включать файл .svn и файлы ревизий для вашего последнего обновления. Это удобно, так как это, вероятно, некоторые из файлов, которые svn просматривает дальше. NTFS не может этого сделать, хотя большие части MFT должны быть кэшированы в системе, они могут не быть теми частями, которые вы захотите затем.

Вы правы в том, что именно здесь живут небольшие файлы, но я не уверен, почему это должно усиливать работу MFT. Разве это не облегчит чтение этих файлов, поскольку вы почти гарантированно извлекаете много этих файлов в кеш при извлечении любого из них? ChrisInEdmonton 14 лет назад 2
@ChrisInEdmonton Это обновления MFT, которые подчеркивают это, потому что вы не касаетесь блоков, где доступно соседнее пространство, вы заканчиваете тем, что перемещаете вещи, а также аннулируете кэшированные части MFT. Я гарантирую, что на бумаге MFT должен быть очень быстрым способом обработки небольших файлов. Это просто не выдерживает на практике. dlamblin 14 лет назад 1
6
Joey

Ну, ваша конкретная проблема заключается в том, что

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

То, что вы видите, - это просто артефакт чего-то, разработанного для конкретной операционной системы с предположениями о производительности в этих операционных системах. Это обычно плохо работает, когда принимается к другим системам. Другими примерами могут быть разветвление или многопоточность. В UNIX-подобных традиционным способом парализации чего-либо является просто порождение другого процесса. В Windows, где процессы запускаются как минимум в пять раз дольше, это действительно плохая идея.

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


Когда-нибудь, когда у меня будет много свободного времени, я планировал написать модуль файловой системы SVN, который использовал бы функции, которые есть у вас в NTFS, такие как поддержка транзакций (должна устранить «касающуюся проблемы с миллионами мелких файлов») и альтернативные данные. потоки (следует исключить необходимость в отдельном .svnкаталоге). Было бы неплохо это иметь, но я сомневаюсь, что разработчики SVN обойдут реализацию таких вещей в обозримом будущем.

Примечание: Одно обновление в большом репозитории SVN, которое я использую, заняло около 250 000 операций с файлами. Какой-то крошечный голос говорит мне, что это действительно много для 24 файлов, которые изменились ...

Но * почему * производительность NTFS ухудшается при работе с миллиардами небольших файлов? Нужно ли жертвовать этим, чтобы получить что-то еще? JesperE 14 лет назад 1
3
Kenneth Cochran

Вот от Microsoft информации о том, как работает NTFS. Это может быть излишним для того, что вы ищете, но изучение может пролить свет на то, с какими сценариями у NTFS возникают проблемы.

Похожие вопросы