5

[Перемещено из моего поста Ask HN. Не стесняйтесь закрыть его, если вопрос слишком широк для суперпользователя.]

Это то, что мне было интересно в течение многих лет, но я никогда не находил хороших обсуждений по этой теме. Конечно, мой Google-фу может просто подвести меня ...

Я часто имею дело с проектами, включающими тысячи относительно небольших файлов. Это означает, что я часто выполняю операции со всеми этими файлами или их большим подмножеством - копирую папку проекта в другом месте, удаляю кучу временных файлов и т.д. Из всех машин, на которых я работал в течение многих лет, я Вы заметили, что NTFS выполняет эти задачи гораздо медленнее, чем HFS на Mac или ext3/ext4 на Linux. Однако, насколько я могу судить, необработанная пропускная способность на NTFS на самом деле не медленнее (по крайней мере, незначительно), но задержка между каждым отдельным файлом лишь чуть-чуть больше. Эта небольшая задержка действительно складывается для тысяч файлов.

(Примечание: из того, что я прочитал, это одна из причин, по которой git испытывает такую боль в Windows, поскольку он так сильно полагается на файловую систему для своей объектной базы данных.)

Конечно, мое свидетельство просто анекдотично - у меня в настоящее время нет реальных цифр производительности, но я бы хотел проверить это дальше (возможно, с Mac с двойной загрузкой в Windows). Тем не менее, моя увлеченность настаивает на том, что кто-то там уже есть.

Может кто-нибудь объяснить это, или, возможно, укажет мне правильное направление для дальнейших исследований?

1 ответ1

3

Я не эксперт по HFS, но я изучал файловые системы NTFS и ext3. Похоже, вы должны рассмотреть две вещи.

Во-первых, файловые системы ext2/3/4 предварительно выделяют области на диске для хранения метаданных файла (права доступа, владение, блоки или экстенты, составляющие данные файла). Я не думаю, что NTFS делает. Эквивалентом ext3 "inode" является запись $ MFT. Насколько я понимаю, записи $ MFT не обязательно уже выделяются при создании файла. $ MFT может быть увеличен в случае необходимости. Гораздо сложнее увеличить число inode в файловой системе ext2/3/4.

Я не знаком с любыми внутренними средствами NT, но все читается так, как будто записи $ MFT создаются по мере необходимости, так что вы можете иметь небольшие файлы, каталоги, большие файлы с чередованием.

Для файловых систем в стиле BSD FFS, которые наиболее определенно относятся к файловым системам ext2/3/4, многие, тем не менее, занимались группировкой дисковых инодов и отделением файлов каталогов от инодов. Многое из этого пошло на написание каталогов и метаданных как эффективно, так и безопасно. См. Http://www.ece.cmu.edu/~ganger/papers/softupdates.pdf в качестве примера.

Во-вторых, данные для небольших файлов хранятся в записях $ MFT, если я правильно читаю. Это не относится к ext2/3/4, и поэтому я упомянул выше, что маленькие и большие файлы обрабатываются немного по-разному.

Мне кажется, что NT (операционная система) страдает от конкуренции за $ MFT. Директории обновляются, что является обновлением записи $ MFT. Создаются небольшие файлы, которые являются обновлением $ MFT. ОС не может упорядочить операции чтения и записи, потому что все обновления метаданных и записи данных идут в один и тот же "файл", $ MFT.

Но, как я уже сказал, просто предположение. Мое знание NTFS в основном из чтения, и лишь очень немного из экспериментирования с ним. Вы можете дважды проверить мои предположения, увидев, что HFT хранит "каталоги" отдельно от "inode" отдельно от "данных файла". Если это так, это может быть большой подсказкой.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .