Почему производительность NTFS такая отвратительная по сравнению, например, с Linux / ext3? Чаще всего я вижу это при проверке (больших) исходных деревьев из Subversion. Оформление заказа занимает около 10-15 минут в NTFS, в то время как соответствующая проверка в Linux (на почти идентичном оборудовании) занимает на порядок быстрее (1 - 1,5 минуты).
Может быть, это специфично для обработки большого количества маленьких файлов, и NTFS лучше, когда речь идет о больших файлах, но почему это должно быть? Разве повышение производительности NTFS для небольших файлов не будет чрезвычайно полезным для производительности Windows в целом?
РЕДАКТИРОВАТЬ: Это не означает, что "NTFS отстой по сравнению с ext3" подстрекательский вопрос; Меня искренне интересует, почему NTFS работает плохо в определенных случаях. Это просто плохой дизайн (в чем я сомневаюсь), или есть другие проблемы, которые вступают в игру?
источник
Ответы:
NTFS имеет эту вещь, называемую Master File Table . Это звучит очень круто, когда вы читаете об этом.
Вы можете видеть, что ext3 нормально работает до 95% использования диска, в то время как наличие MFT означает, что NTFS на самом деле не хочет, чтобы вы использовали более 90% вашего диска. Но я предполагаю, что это не ваша проблема, и что ваша проблема связана с множеством операций над множеством маленьких файлов.
Одно из отличий заключается в том, что происходит, когда вы создаете небольшой файл. Если файл меньше размера блока, он не записывается в свой собственный блок, а хранится в MFT. Это хорошо, если файл остается точно таким же, каким он был при создании. Однако на практике это означает, что когда svn касается файла, чтобы создать его, затем добавляет к этому файлу, удаляет из него или просто модифицирует его, когда его недостаточно для перемещения в собственный блок, операция выполняется довольно медленно. Также простое чтение большого количества маленьких файлов создает некоторую нагрузку на MFT, где они все находятся, с кратными на блок. Зачем это делать? Это упреждающий отказ от фрагментации и более эффективное использование большего количества блоков, и в целом это хорошо.
В ext2 и 3, напротив, файловые блоки для каждого файла хранятся рядом с тем местом, где находятся метаданные каталога для каталога, в котором они находятся (когда это возможно, если ваш диск нефрагментирован и у вас есть около 20% свободного места). Это означает, что когда svn открывает каталоги, ряд блоков кешируется в основном бесплатно в этом 16-мегабайтном кеше на вашем диске, а затем снова в кеш-памяти ядра. Эти файлы могут включать файл .svn и файлы ревизий для вашего последнего обновления. Это удобно, так как это, вероятно, некоторые из файлов, которые svn просматривает дальше. NTFS не может этого сделать, хотя большие части MFT должны быть кэшированы в системе, они могут не быть теми частями, которые вы захотите затем.
источник
Ну, ваша конкретная проблема заключается в том, что
То, что вы видите, - это просто артефакт чего-то, разработанного для конкретной операционной системы с предположениями о производительности в этих операционных системах. Это обычно плохо работает, когда принимается к другим системам. Другими примерами могут быть разветвление или многопоточность. В UNIX-подобных традиционным способом парализации чего-либо является просто порождение другого процесса. В Windows, где процессы запускаются как минимум в пять раз дольше, это действительно плохая идея.
В общем, вы не можете просто взять какие-либо артефакты конкретной ОС, которые будут предоставлены на любой другой с совершенно другой архитектурой. Также не забывайте, что NTFS имеет много функций файловой системы, которые отсутствовали в файловых системах UNIX, широко используемых на тот момент, таких как ведение журнала и ACL. Эти вещи стоят дорого.
Когда-нибудь, когда у меня будет много свободного времени, я планировал написать модуль файловой системы SVN, который использовал бы функции, которые есть у вас в NTFS, такие как поддержка транзакций (должна устранить «трогательную проблему миллионов мелких файлов») и альтернативные данные. потоки (следует исключить необходимость в отдельном
.svnкаталоге). Было бы неплохо это иметь, но я сомневаюсь, что разработчики SVN обойдут реализацию таких вещей в обозримом будущем.Примечание: одно обновление в большом репозитории SVN, которое я использую, заняло около 250 000 операций с файлами. Какой-то крошечный голос говорит мне, что это действительно много для 24 файлов, которые изменились ...
источник
Вот от Microsoft информации о том , как работает NTFS. Это может быть излишним для того, что вы ищете, но изучение может пролить свет на то, с какими сценариями у NTFS возникают проблемы.
источник