В процессе обсуждения вопроса производительности реализации файловых систем на уровне ядра и работающих через FUSE Антон Альтапармаков из компании Tuxera, занимающейся разработкой NTFS-дайверов, заявил (http://article.gmane.org/gmane.linux.file-systems/54990), что работающий на уровне Linux-ядра NTFS-драйвер не только опережает реализацию NTFS на уровне пользователя, но и заметно обгоняет по производительности файловые системы Ext3 и Ext4.Приведенная информация свидетельствует о том, что реализация NTFS на уровне ядра обеспечивает пропускную способность при записи примерно 190 Мб/сек, в то время как результаты Ext4 и FAT32 составляют 100 Мб/сек, Ext3 - 75 Мб/сек, а NTFS-3G - 15 Мб/сек. Причиной подобного превосходства в скорости записи по мнению Антона является (http://article.gmane.org/gmane.linux.kernel/1154040) реализация в NTFS-драйвере технологии отложенного обновления мета-данных.
URL: http://www.phoronix.com/scan.php?page=news_item&px=OTU5Ng
Новость: https://www.opennet.ru/opennews/art.shtml?num=30986
вот только имеется ввиду не открытый ntfs-3g (fuse), а проприетарный ядерный драйвер
> вот только имеется ввиду не открытый ntfs-3g (fuse), а проприетарный ядерный драйверА, тогда понятно: сам себя не похвалишь - никто не похвалит. Проприетарщики такие проприетарщики...
Интересно, а этот господин не хочет предоставить полный материал для повторения бенчмарков, включая драйвера, описание конфигураций и все методики и особенности? Ах ну да, оно же только для производителей, бла-бла-бла. Румяным менеждерам которых можно навешать лапшу на уши. Видимо маловато менеджеров пока на поклон приходит.
Какая блжад разница какой драйвер имеется в виду? On disk format от этого меняется что ли?
а вы с какой скоростью печатаете? 2000знаков в минуту, но такая фигня получается)))
по-моему, это так называемый "троллинг".
а вообще - "не верю" (с) :)
пиар...
а хде reiserfs?
он то на мелочи уделает
да и размера файлов не вижу
0 цена словам этого Антона
> NTFS на уровне ядра обеспечивает пропускную способностьА ничего что пропускная способность от дисков зависит? Сейчас специально померил - это поделие в полтора раза медленее Ext4.
Откуда у вас «это поделие»? Вы работаете в Туксере?
а... ну ещё бы https://www.opennet.ru/opennews/art.shtml?num=29205
А вот местные аналитики так много рассказывали, что NTFS настолько отсталая система, что почти любая линуксовая ее обгоняет по скорости, надежности или фичам, а обычно всему вместе..Кому верить?
Конечно же кондитерской фабрике, утверждающей, что её конфеты - самые вкусные в мире.
Провести эксперимент на нескольких машинах и верить результатам.
для этого еще эксперимент надо проводить грамотно, на одном и том же разделе диска форматируя его под разные фс, с перезагрузками перед тестированием. При этом тщательно изучив опции форматирования и монтирования у каждой ФС. А то будет одна фс с журналом, а другая без и т п.
Это если цель получить объективный результат. А если продажи надо толкать, с такими методами можно остаться в позе "зубы на полке" ;)
Антон Альтапармаков утверждает, что правильный результат - только для разработчиков!
Тогда уж мог бы и сразу уточнить "покупайте наших слонов" :)
> Провести эксперимент на нескольких машинах и верить результатам.НЕ правильно. Провести эксперимент ПРАВИЛЬНО и НЕПРЕДВЗЯТО, а то есть любители "на самом деле медленнее в 10 раз, сам мерил" и тому подобные эксперты...
> Провести эксперимент на нескольких машинах и верить результатам.Только вот мистер пиарщик из указанной компании...
1) Забыл предоставить методику тестирования.
2) Забыл предоставить описание конфигураций.
3) Забыл предоставить свой кульный драйвер для проведения независимых тестов.Форд выпускает самые хорошие машины. По мнению Форда ;)
Верить следует себе и своему опыту. Вот мой опыт подсказывает, что эта ФС хорошая для винды и только для винды, но при работе с большими файлами, а на маленьких она откровенно сдыхает, тогда как та же ext4 показывает . По надежности тоже хороша, но fsck работает на порядок дольше, чем с ext4, а проверять при падении машины нужно обязательно (корневой раздел портится часто, зато винда почему-то не запускает полную проверку раздела, восстанавливая только журнал, а ошибки накапливаются - в итоге можно загубить раздел). По возможностям, как мне кажется, ничуть не лучше классических фс, но заметно уступает продвинутым, поскольку писалось при царе Горохе в ИБМ.Только весьма странный человек станет пользоваться нтфс под линюкс в качестве основной фс. А если так, так зачем тогда все эти вздохи и охи? Для совместимости - да, для работы - а ну ее куда подальше вместе с туксерой и прочими подмелкомягкими.
> ФС хорошая для винды и только для винды,Она не то что хорошая, просто ничего лучше в винде все равно нет и не будет. Это примерно как самолет: тошнит, а выйти некуда.
Верное сравнение, самолеты до сих пор проектируют по эмпирически выведенным данным.
Выковыривание при помощи R-Studio чертежей, пояснилки и литературы из ntfs-ного раздела дважды за месяц перед защитой более чем меня в этом убеждает. К слову reiserfs без единого слета и восстановления дерева работает на этом же харде уже 5 лет без перерыва.
Простите, а ви пробовали на системном разделе данные не хранить и не вляпывать в ось что попало? У меня восьмой год без передышки молотит NTFS-разде ли никаких проблем. Я что-то делаю не так?
Для важных данные придумали делать бекапы. Вы уверены, что именно NTFS портит Ваши данные, а не физическая неисправность жесткого диска? Хвалить\ругать NTFS не хочу, однако, мне кажется, это вполне стабильная и надежная ФС, естественно, со своими достинствами и недостатками, как и все прочие
Пошёл подписываться на news://news.gmane.org:119/gmane.linux.file-systems
В ext3, ext4 есть, например, журнал, а в NTFS?> Причиной подобного превосходства в скорости записи по словам Антона является реализация в NTFS-драйвере технологии отложенного обновления мета-данных.
Если мерять тупые FS, то vfat порвёт всех на скорость записи.
И как там с sync работает при отложенной записи? В reiserfs этот sync может убить все её преимущества по работе с мелкими файлами.
А в NTFS он то-же есть.
> А в NTFS он то-же есть.Если sync сбрасывает информацию на диск, то автор врёт -- на больших файлах скорость на xfs почти равна линейной скорости записи (и судя по скорости -- тут меряли большие файлы), а на мелких sync убъёт скорость -- полное кеширование этого есть только в reiserfs, но в случае сбоя у reiserfs журнал откатит все баги, а если такое же кеширование у ntfs, то неизбежна порча данных fs и значит этот драйвер ни на что кроме мерялки "а у кого больше" не годен.
Автор не врёт, он говорит _только_ о cached write. Ну сходите по ссылкам.
> Автор не врёт, он говорит _только_ о cached write. Ну сходите по
> ссылкам.Автор упоминает, что размер кэша всего 64 kiB и размер памяти у машины 512 MB, что совсем мало для заметного влияния на скорость за счет почти полного кэширования в ОЗУ.
Ну так и пишет он не мегабайты. Если бы кеширования не было — он бы не писал о кешированной записи, да и аппаратура не позволила бы такую скорость (190 МиБ/с). Цель его экспериментов — уменьшить торможение внутри драйвера. Удалось.
> Автор не врёт, он говорит _только_ о cached write. Ну сходите по
> ссылкам.К тому же ext4 и сотоварищи тоже с кэшированием тестировались.
Ну так для ext4 сотоварищи оптимизация, подобная той, что сделал Антон за последние полгода для exFAT и NTFS, _пока_ не проводилась. Никто и не утверждает, что для них нельзя так же соптимизировать. Найдется умелец — соптимизирует, догонит ext4 NTFS (скорость скорее всего ограничена скоростью копирования памяти юзерспейс-ядро). Или не догонит, если такую оптимизацию сочтут опасной и ненужной.
> в случае сбоя у reiserfs журнал откатит все баги, а если такое же кеширование у ntfs, то неизбежна порча данныхNTFS тоже работает по принципу баз данных, с журналами отката.
>> в случае сбоя у reiserfs журнал откатит все баги, а если такое же кеширование у ntfs, то неизбежна порча данных
> NTFS тоже работает по принципу баз данных, с журналами отката.У ntfs вообще нет нормального журнала как в ext3, ext4, а у reiserfs всегда активен полный журнал, не только метаданных.
Просто обеспечение целосности метаданных -- это ещё не журнал.
Так же как полно нетранзакционных баз данных.
>>> в случае сбоя у reiserfs журнал откатит все баги, а если такое же кеширование у ntfs, то неизбежна порча данных
>> NTFS тоже работает по принципу баз данных, с журналами отката.
> У ntfs вообще нет нормального журнала как в ext3, ext4, а у
> reiserfs всегда активен полный журнал, не только метаданных.
> Просто обеспечение целосности метаданных -- это ещё не журнал.
> Так же как полно нетранзакционных баз данных.В.1) Упомянутые вами "нетранзакционные базы данных" - поддерживают ли транзакционность на логическом (но не на физическом) уровне? Если нет, то ваше сравнение некорректно, NTFS то полностью поддерживает транзакционность на логическом уровне.
В.2) Можно полный список известных вам упомянутых "нетранзакционных баз данных" (чтобы четче проверить ваш ответ на мой вопрос В.1)?
"You might say that ext3/4 are journalling so not a fair comparison so let me add that FAT32 achieves about 100MiB/s in the same hardware/test, still about half of NTFS."
> "You might say that ext3/4 are journalling so not a fair comparisonЕго отложенная запись метаданных скорее всего в случае краха приведет к потере очень большого объема данных. В классическом "транзакционном" дизайне журналирующих ФС, каковым является NTFS, можно работать или быстро, или надежно.
Я наверное чего то не понял. Но у них на сайте, на графиках, разрыв совсем не такой о котором пишут тут.
http://www.tuxera.com/products/tuxera-ntfs-embedded/performance/
А как на счет того драйвера, который в ядре уже с начала двухтысячных был, который долго не рекомендовали использовать на запись, я его до появления ntfs-3g использовал. Как он работает? Кто нибудь пробовал? Вроде он сейчас и на запись стабильный.
если не ошибаюсь, эти проекты объединились
Ядерный драйвер и ntfsprogs -- это разные вещи, т.е. драйвер и набор утилит для обслуживания.
моё видение картины:
http://s2.ipicture.ru/uploads/20110625/V4W6h5RU.jpg(как-то раз интересовался)
Нарисовать рукой на бумаге и сфотографировать - гениально!
Без тестов от фороникса это заявления нечего не стоит))))
Ну а новость-то откуда взяли? ;)
вы видели миниатюру "пиарим свой стартап троллингом"
Автору новости — приз за фигурную подачу материала.1. Компания Tuxera не считает NTFS самой быстрой ФС для Linux. Речь вообще о преимуществе ядерных драйверов над FUSE (и ядерного драйвера NTFS, над которым работал Антон, в частности).
2. Результаты приведены не просто записи данных, а для кешированной записи. Запись большого потока данных Антон сам считает мало зависящей от ФС и ограниченной устройством вывода.
3. Превосходство в этом тесте драйвера NTFS не над всеми ФС, а только над протестированными (Ext3, Ext4, XFS и FAT32). Рейзер не тестировался, о нём никто и не говорит.
Итого — громкий заголовок, наброс, скандал — из ничего.
> 2. Результаты приведены не просто записи данных, а для кешированной записи. Запись
> большого потока данных Антон сам считает мало зависящей от ФС и
> ограниченной устройством вывода.Он это упоминает в контексте записи от одного процесса: "But yes if you confine yourself to a single i/o stream with large i/os, with only one process doing it, and you use direct i/o obviously just about any optimized file system can achieve close to the actual device speed, no matter whether in kernel or in user space."
Только вот в реальных условиях непрерывная линейная запись только одним процессом редко встречается.
> 3. Превосходство в этом тесте драйвера NTFS не над всеми ФС, а
> только над протестированными (Ext3, Ext4, XFS и FAT32). Рейзер не тестировался,
> о нём никто и не говорит.Рейзер уже давно заброшенный анахронизм. Другие непротестированные, либо специфичны для каких-то определенных применений, либо еще не вышли из разряда экспериментальных.
Там достаточно громкое заявление "That is why the in-kernel Tuxera NTFS driver now outperforms all other file systems that have been tested (whether in kernel or in user space including ext*, XFS and FAT)."
> Он это упоминает в контексте записи от одного процесса: "But yes if
> you confine yourself to a single i/o stream with large i/os,
> with only one process doing it, and you use direct i/o
> obviously just about any optimized file system can achieve close to
> the actual device speed, no matter whether in kernel or in
> user space."Верно, в этом случае достигается максимальная скорость записи, ограниченная возможностями устройства, и достоинства ФС и драйвера тут малую играют роль (поэтому юзерспейсовый драйвер может не сильно отстать от ядерного, об этом речь). В остальных случаях скорость будет ниже, и особенности ФС уже будут иметь значение.
> Только вот в реальных условиях непрерывная линейная запись только одним процессом редко
> встречается.В некоторых применениях (эмбедщина, запись фото/видео в камере) это как раз типичный сценарий. А так реальные условия бывают очень разными.
> Рейзер уже давно заброшенный анахронизм. Другие непротестированные, либо специфичны для
> каких-то определенных применений, либо еще не вышли из разряда экспериментальных.Ну, кое-кто тут упомянул рейзер. ;)
> Там достаточно громкое заявление "That is why the in-kernel Tuxera NTFS driver
> now outperforms all other file systems that have been tested (whether
> in kernel or in user space including ext*, XFS and FAT)."_that have been tested_. И речь только об определённых тестах, о которых говорилось выше.
Кстати, не удивлюсь, если этот новый оптимизированный драйвер порвёт как тузик грелку и оригинальный виндовый.
Нафиг-нафиг этот NTFS!!!
В эти новогодние праздники в моей конторе грохнулось сразу три сервера по причине "порчи" сразу всех копий MFT$.
Данные удалось частично вытащить, а причину найти так и не удалось. Винты - чистые, без Bad-ов, вирусни нет... Просто после очередного update серверам нужно было перезагрузиться, они ушли на перезагрузку и... Заблудились...Теперь на NTFS у меня исключительно сама Windows. Все данные вынесены в NAS-ы.
SQL-базы - reiserfs, пользовательские данные - ZFS.NTFS - очень странный зверёк: может спокойно пережить пару-тройку резетов в процессе дефрагментации, а может "лечь" без причин.
Ну так ССЗБ. Зачем было использовать NTFS кроме как для Windows?
> Ну так ССЗБ. Зачем было использовать NTFS кроме как для Windows?А майкрософт типа святой, да? Нормальненький такой баг? Подумаешь, всего-то полное разрушение тома: http://support.microsoft.com/kb/2249857
1. И причём тут NTFS?2. Вам ещё не надоело выказывать уровень своей подготовленности, явно недостаточный для беседы по теме?
3. У вас какие-то психологические проблемы, что ли, что вы везде видите рекламу MS?
> 1. И причём тут NTFS?У NTFS есть странная особенность: при обнаружении "поломанной" копии MFT$ она "восстанавливает" её, используя вторую копию. Иногда (не разбирался ни разу при каких обстоятельствах) "восстанавливается" исправная копия. То есть "неисправная" копия MFT$ берётся за "образец".
Так что NTFS - весьма своебразный зверёк.
>> 1. И причём тут NTFS?
> У NTFS есть странная особенность: при обнаружении "поломанной" копии MFT$ она "восстанавливает"
> её, используя вторую копию. Иногда (не разбирался ни разу при каких
> обстоятельствах) "восстанавливается" исправная копия. То есть "неисправная" копия MFT$
> берётся за "образец".
> Так что NTFS - весьма своебразный зверёк.Это относилось не к вам, а к Анониму, сующему ссылку на KB с описанием одного и того же бага Windows (других не смог найти, что ли) в разных новостях, причём почему-то постоянно не по теме.
> Ну так ССЗБ. Зачем было использовать NTFS кроме как для Windows?Так под Windows и было... То есть Windows закоцал свою FS.
> SQL-базы - reiserfs3й reiserfs хорош только для кучи мелких файлов, на больших запись уже заметно притормаживает, а так же он однопоточен.
Тут лучше xfs использовать (её ранее Oracle советовала под свои базы), но система должна быть 64-битной, иначе лучше ext4 или zfs, в зависимости от OS.
>> SQL-базы - reiserfs
> 3й reiserfs хорош только для кучи мелких файлов, на больших запись уже
> заметно притормаживает, а так же он однопоточен.
> Тут лучше xfs использовать (её ранее Oracle советовала под свои базы), но
> система должна быть 64-битной, иначе лучше ext4 или zfs, в зависимости
> от OS.Согласен. Неправ. Исправляюсь.
>SQL-базы - reiserfs,О-о-о, батенька. А не боитесь той же участи, что и в случае использования NTFS для серверов?
>>SQL-базы - reiserfs,
> О-о-о, батенька. А не боитесь той же участи, что и в случае
> использования NTFS для серверов?Боюсь. Второй год уже... ;)
А вообще - ваша правда. XFS, наверное, лучше подойдёт.
Есть парк машин с хрюшей ~200, ntfs валится с завидной регулярностью (1-раз в 2 недели)
И такой же с debian, за два года ни одного разрушения с потерей данных.
Кривые руки операторов и железо одни и теже.
ЗЫ. Виньда - самая передовая ось в мире, т.к. никогда не оставит итешников без работы. Надо же кому-то ее восстанавливать.