27 июня 2011, 12:30

Tuxera: Наша реализация NTFS быстрее других файловых систем в Linux

Реклама решений Tuxera NTFS
Иллюстрация с сайта Tuxera

Антон Альтапармаков (Anton Altaparmakov), ведущий разработчик компании Tuxera, сделал весьма громкое заявление, сообщив в почтовой рассылке linux.file-systems, что NTFS является самой быстрой файловой системой… в Linux.

Tuxera — финская компания, основной бизнес которой построен на продаже коммерческих продуктов в виде реализации NTFS для Mac OS X и других ФС (exFAT, FAT и т.п.) для встраиваемых систем. Ее сотрудник Альтапармаков давно известен в Open Source-среде благодаря разработке драйвера NTFS для ядра Linux. Реализация NTFS от Tuxera на уровне ядра Linux (т.е. не требующая FUSE и не работающая в пользовательском пространстве) так и остается закрытой, но разработчик не преминул возможностью похвастаться ее достижениями.

Из письма Антона в linux.file-systems: «[..] драйвер для [Linux-]ядра Tuxera NTFS быстрее, чем вообще может быть любой другой userspace-драйвер для NTFS. Он еще и быстрее, чем ext3/ext4. На примере встраиваемой системы (процессор 800 МГц, 512 Мб RAM, размер буфера записи — 64 КиБ) NTFS в пользовательском пространстве достигает максимальной скорости кэшируемой записи в ~15 МиБ/с, ext3 — ~75 МиБ/с, ext4 — 100 МиБ/с, а Tuxera NTFS kernel driver — ~190 МиБ/с, превосходя ext4 вдвое, а реализацию NTFS в пользовательском пространстве — в 10 раз. У файловых систем в пользовательском пространстве есть свои применения, но высокая производительность — это не одно из них… Вы можете сказать, что ext3/4 являются журналируемыми, поэтому нечестно так сравнивать, но тогда я добавлю, что FAT32 достигает скорости в 100 МиБ/с на том же оборудовании в том же тесте, чем всего вдвое уступает NTFS».

В последующем письме он же напишет, что благодаря реализованному им механизму «отложенных обновлений метаданных» реализация Tuxera NTFS для ядра Linux «превосходит все другие протестированные файловые системы», среди которых называются разные версии ext, XFS и FAT.

Постоянная ссылка к новости: http://www.nixp.ru/news/11271.html. Дмитрий Шурупов по материалам phoronix.com, Article.Gmane.org.

Linux, NTFS, Tuxera, файловые системы

Комментировать (11)

Дмитрий Шурупов 13:09, 27 июня 2011

До кучи — Торвальдс на днях вот так вбросил про файловые системы в пользовательском пространстве: «People who think that userspace filesystems are realistic for anything but toys are just misguided». При этом он не до конца пояснил, почему так (кроме фразы: «fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device»). С ним не согласились, например, Pete Zaitcev и CloudFS.

Ответить Цитировать

defender 15:07, 27 июня 2011

Ну Линус вообще славится своим дурным отношением к микроядерным архитектурам. И собственно не так далек от истины как по мне — IA-32 да и x86_64 имеют очень слабые места в ентом деле. С таким количеством переключений контекста производительность и вправду будет уж очень аховая…

Ответить Цитировать

Дмитрий Шурупов 15:09, 27 июня 2011

Да, там и про любимое микроядро было: «That’s like saying you should do a microkernel — it may sound nice on paper, but it’s a damn stupid idea for people who care more about some idea than they care about reality.» (это продолжение его реплики про userspace file systems) ;-)

Ответить Цитировать

defender 15:00, 27 июня 2011

Ну, во-первых, есть хороший анекдот на тему «ну и вы говорите». Где результаты тестов? Кто может подтвердить? Какие были тесты? Каждая файлуха имеет свой «конек» и свои недостатки. к тому-же, был ли включен у ext4 journal_async_commit, какой режим журнала? И почему не упоминается btrfs? У нее уже есть COW даже а не только асинхронная алокация инодов. Афтор крут, но фтопку такие заявы.

Ответить Цитировать

Дмитрий Шурупов 15:07, 27 июня 2011

Господа из Phoronix горят желанием протестировать, кстати: «If we are able to get our hands on Tuxera NTFS to test these claims, we will be glad to do so». Если Tuxera хочет попиариться всерьёз, она должна воспользоваться этим прекрасным предложением ;-)

Ответить Цитировать

rgo 23:24, 27 июня 2011

Мне, почему-то кажется, что дело тут не столько в реализации ntfs-драйвера, сколько в структуре самой файловой системы и условиях проведения теста. Ну, например, речь могла идти о записи большого-большого файла на изначально пустую fs. Я не настолько знаток структуры ntfs, чтобы судить безапелляционно, но насколько я наслышан об этой структуре, мне кажется, что если писать много, на пустую фс и одним файлом, то придётся совершать гораздо меньше телодвижений, чем в случае с *nix-like фс, типа ext*.

Да вы гляньте на результаты FAT32. Они на уровне ext4. fat32 — это файловая система из прошлого века, убогая и тормозная. Одна из причин, почему MS разрабатывала NTFS — это тормознутость FAT32. Если fat32 сравнялась с ext4, значит условия теста были намеренно подогнаны под структуру файловой системы типа FAT/NTFS, в которой все файлы описаны во едином массиве/списке, как бы он не назывался — FAT или MFT.

[offtop]А на моём подыхающем жёстком диске эта ntfs тормозила бы так же, как сейчас тут тормозит ext4… =([/offtop]

Ответить Цитировать

defender 02:57, 28 июня 2011

Ну, условия проведения теста одинаковы для всех файлух. И таки да FAT довольно шустрая фс-ка когда дело касается крупных файлов. И таки основной причиной написания NTFS было не тормознутость а ограничения на размер файла, каталога, ФС-ки. Отсутствие журнала. Кстати, режим журнала для ext4 — очень важен. Так как NTFS например журналирует только метаданные и притом в режиме, аналогичном writeback для etx3/4.

Ответить Цитировать

dfghm 17:19, 28 июня 2011

Основной причиной разработки NTFS было отсутствие поддержки прав доступа к файлам — NT File System. Или я ошибаюсь?

Ответить Цитировать

rgo 23:15, 28 июня 2011

Я ничего не говорил про «основную» причину. Я говорил про «одну из» причин. ;) Хотя я, пожалуй, неправильно выразился: надо было говорить про одну из целей, которую преследовали разработчики при создании ntfs.

Я не знаю основной причины создания ntfs, но склоняюсь к мнению Exploit Fate: поддержка acl была основной причиной. Всё остальное, на момент создания ntfs, было неактуально. Я не уверен, что тогда существовали жёсткие диски в два гигабайта, но то, что никому в голову не приходило складывать два гига информации в один файл — в этом я уверен точно. То есть нововведения призванные увеличить ёмкость фс и ёмкость файла этой фс были заделом на будущее.

А то что условия теста одинаковы — это понятно, другое дело что эти условия были заточены на NTFS/FAT. Выражаясь точнее, это я так думаю, что условия были заточены. Что же было на самом деле, мы (надеюсь) узнаем в скором будущем.

Ответить Цитировать

defender 02:04, 29 июня 2011

По поводу размера: RAID был придуман для этого дела еще очень давно. И базы данных опухли до размеров многих гигов уже давно.

По поводу ACL — HPFS, драйвер которой был в винде начиная с NT 3.1 и вплоть до 2к, таки поддерживает ACL-и (HPFS386).

Ну, это так промежду прочим…

И производительность у HPFS уже во времена NT 3.1 была на высоте (по сравнению с FAT), уже тогда там были екстенты (что в примципе означает отсутсвие ну почти конечно ограничений на размер файлов и файловой системы — ограничивалось только константами в коде и разрядностью машины) и B*-дерево как структура каталогов.