LINUX.ORG.RU

Сравнение быстродействия нативного порта ZFS и Ext4/BtrFS/XFS в Ubuntu 10.04 LTS

 , , , , , ,


1

1

Аналитики Phoronix.com произвели серию тестов различных файловых систем в Ubuntu 10.04. Для поддержки файловой системы ZFS в Ubuntu 10.04 LTS использовался модуль разработанный компанией KQ Infotech. В отличие проекта разрабатываемого по заказу LLNL модуль KQ Infotech поддерживает ZFS Posix Layer (ZPL), поэтому можно работать с файлами с помощью обычного файлового менеджера.

Вот какие результаты были получены:

  • В тесте Apache Benchmark v.2.2.11 самой производительной оказалась Ext4, а ZFS самой медленной
  • SQLite v.3.6.19 самой производительной оказалась XFS, а ZFS самой медленной Правда ZFS в OpenIndiana b147 показала бо́льшую производительность чем XFS в Ubuntu 10.04 LTS
  • В тесте Compile bench v.0.6 на сей раз самой производительной оказалась Ext4, чуть отстала Btrfs, предпоследние место заняла ZFS, а самую худшую производительность показала XFS. ZFS в OpenIndiana b147 показала производительность меньше чем Btrfs, на больше чем ZFS в Ubuntu 10.04 LTS
  • В тесте I/O Zone v.3.347 при размере файлов 64k лучшую производительность показала Btrfs, а худшую ZFS
  • В тесте I/O Zone v.3.347 при размере файлов 4k теперь ZFS на втором месте, Btrfs снова в лидерах, а на последнем месте оказалась XFS
  • В тесте FS-Mark v.3.3 в лидерах Ext4, на втором месте ZFS, а Btrfs показала худший результат
  • В тесте Threaded I/O Tester v.0.3.3 теперь в лидерах ZFS, Btrfs показала чуть худший результат, а на последнем месте оказалась Ext4

>>> Подробности

Ответ на: комментарий от anonymous

>NTFS - вот это поистине неубиваемая файловая система.
Только если сломается что-то до chkdsk (что бывает достаточно часто), то восстанавливать ФС нужно будет с livecd. В ext* обычно хотя бы read-only монтирование работает.

x3al ★★★★★
()
Ответ на: комментарий от x3al

>> что бывает достаточно часто
Увы, у меня почему-то не ломается.

восстанавливать ФС нужно будет с livecd.

Ниразу не приходилось так делать. Штатного chkdsk всегда хватало.

В ext* обычно хотя бы read-only монтирование работает.

А это уже как повезет, и зависит от степени испорченности ФС/винта. И если сильно нужно (для чего?) — что мешает смонтировать NTFS-раздел в ro в том же линуксе?

wintrolls ☆☆
()
Ответ на: комментарий от x3al

>Только если сломается что-то до chkdsk (что бывает достаточно часто), >то восстанавливать ФС нужно будет с livecd.

Бывает. Такое чаще всего происходит по причине БЭД-ов, пусть даже и софтовых(на горе тех кто любит пинать свой комп и стучать буком об стол). Но от подобного не застрахована не одна ФС впринцыпе. А то что Винду нельзя запустить в режиме RO - ну блин, такая у нее архитектура. Ей для запуска одного файла-ядра недостаточно. Но это скорее проблема винды, а не НТФС. Да и то, установочный диск с ХП, не говоря уж про старшие модели, содержит необходимые средства для решения подобных проблем. И после прохода чекдиска все файлы целы(не считая крайнередких, единичных случаев). Всеж, с баблом мелкософта, написать ФС(или купить) не составляет труда. Но они этого не делают уже 10ть лет, как был НТФС так и остался. Это уже о чем то говорит.

А по теме, блин, ИМХО Ext4 отличная ФС. Быстрая, журналируемая, вполне надежная. А народу видимо скучно, или пипис-й мерятся желание есть. Все изобретают да портируют. Лучшеб Ext4 пилили, чтоб она еще лучше была. Ее одной, хорошо допиленной ИМХО более чем достаточно как для серверов так и для десктопа. А снапшоты и прочая подобная лабуда - это ИМХО дела 10-е, барство и не более. И без них спокойно можно жить, и подобный функционал можно подругому реализовывать(пусть и не в такой мере и не так удобно). Главное чтоб ФС, была быстрая(и на запись тоже), надежная, если и ломается - чтоб быстро и просто чинилась. Ближе всех сейчас к этому Ext4. Зачем ZFS и BtrFS, когда они как ФС почти гавно.

anonymous
()
Ответ на: комментарий от wintrolls

>что мешает смонтировать NTFS-раздел в ro в том же линуксе?

Зачем его в RO. Вероятность таким образом прочитать под Линуксом испорченую НТФС практически равна 0! Да и испорченный НТФС(как и фат) под Линуксом вообще монтировать не надо, если хоть какая-либо ценность в почти потеряных данных есть.

anonymous
()
Ответ на: комментарий от anonymous

>А снапшоты и прочая подобная лабуда - это ИМХО дела 10-е, барство и не более

в этом случае, теоретически, если написать «прямой» драйвер для нтфс на линух, то ехт4 будет просто не нужна на 99% машин. Однако все упирается, как это всегда бывает с линухом, в криворукость реализации - ну в принципе не напишут они ничего стоящего в этом плане и еще лет 30 будут плодить новые фс, каждая из которых ограниченно хороша только в узком кругу требований.

ЗЫ - чего уж говорить, если «умельцы» из лагеря линуксоидов до сих пор не могут портировать ехт2,3 на венду (конечно, принцип написания ПО под венду и линух в этом плане координально отличается, но не в этом суть) - в лучшем случае можно юзать ext2fs, которая дает от силы 10мб/с с юсб винта, при вендовой скорости 30. А если брать прочие поделия вроде linuxreader, то там скорость порядка 2-4 мбайт

anonymous
()
Ответ на: комментарий от anonymous

>в этом случае, теоретически, если написать «прямой» драйвер для нтфс >на линух, то ехт4 будет просто не нужна на 99% машин.

Да, но есть несколько «НО». Врятли стоит сомневаться в факте того, мелкософт НТФС патентами обложил по самые помидоры. Как тока нтфс под линуксом получит хоть какое-либо распространение(если его вообще в ядро пустят), мелкософт как набегут да как завоняет. Но ИМХО, если под Ext4 сделать четкий дефрагментатор, прикрутить ACL-и, прикрутить чтоб по умолчанию было, как радное(и работало так-же), а не чтоб его нужно было где-то там включать, да еще и софт эти ACL почти не поддерживает(а надо, но это не проблема ФС) и добавть еще чуть-чуть скорости и надежности(думаю что со временем это придет), то в общем то НТФС будет не нуден(шифрование силами ФС и сжатие тоже особо никому не нужно, на этом можно не заморачиваться ИМХО). Ну а дальше можно уже по чуть-чуть наращивать функционал - мое сугубо личное ИМХО.

anonymous
()
Ответ на: комментарий от anonymous

>> если его вообще в ядро пустят
Какбы уже давно есть, но только ro.

сжатие тоже особо никому не нужно

Экономит место и увеличивает быстродействие на современных процессорах.

если

сделать


прикрутить


добавть


Если бы, да кабы.

то в общем то НТФС будет не нуден

Вывод — в нынешнем виде Ext4 ненужен?

wintrolls ☆☆
()
Ответ на: комментарий от wintrolls

>Какбы уже давно есть, но только ro.

В такой реализации, что считай что его там нет(или я что-то пропустил). Опять-таки, режим RO - толком то и не нужен. Для повседневного использования есть ntfs-3g, который в случае притензий всегда можно быстро выкинуть из дистрибутива, да и вообще сказать что линукс не при делах. А с полновесным модулем в ядре можно еще той паники агрести, когда правообладатель придет с патентом. Опять таки, хорошо-бы его, в нормальной реализации в качестве основной ФС поиметь, но это фантастика.

Экономит место и увеличивает быстродействие на современных >процессорах.

С тем сжатием, что в НТФС - особо не экономит места да и про скорость - капейки, а проблем в случае повреждения ФС тока прибавит.

Если бы, да кабы.

Ну, вот так.

Вывод — в нынешнем виде Ext4 ненужен?

Вывод - даже в текущем состоянии, очень нужен, но если допилить - будет еще больше желан и нужен. Но даже в текущем состоянии, куда более нужен чем всякие порты сановских ФС. ИМХО - Ext4 лучшая ФС под линь на текущий момент. Лучшеб те усилия, что тратия на порт SunOS, пустили бы на допиливание Ext4 - но такой расклад событий, скорее всего тоже фантастика.

anonymous
()
Ответ на: комментарий от Napilnik

>NTFS уже дружит с ресетами?

Плоховато. Пару раз отключили электричество - винекапец пришел.

Поставил линупс на XFS. С тех пор раз десять отключали, система жива-здорова. Даже упсу раздумал покупать.

anonymous
()
Ответ на: комментарий от anonymous

>винекапец пришел.

В смысле, винДекапец.

Вайн на xfs нормально отключение переносит.

anonymous
()
Ответ на: комментарий от anonymous

>Плоховато. Пару раз отключили электричество - винекапец пришел

вот только на лоре можно такое услышать

anonymous
()
Ответ на: комментарий от anonymous

>Вывод - даже в текущем состоянии, очень нужен

есть понятие «лучшее из лучших», есть «лучшее из имеющихся» - так вот, ехт4 - это 2-е, точнее его можно описать так «более-менее вменяемая фс, которая не очень сильно тормозит и теряет данные только через раз - лучшего пока нет и не предвидется в ближайшем будущем (лет так на 50 вперед)»

anonymous
()

Все вполне логично. XFS самая производительная на больших файлах, но на куче мелких (типа как при компиляции) проигрывает. Жалко нет тестов рейзер4, думаю она бы себя показала на мелких файлах получше чем бтрфс с ехт4. ZFS закономерно самая тормозная. В последнем тесте видимо проявились какие-то оптимизации на многопоточность.

zsh
()
Ответ на: комментарий от iZEN

собственно, анонимус обосновывал то, что нтфс надежная фс, в том числе благодаря 2-м блокам мбр. По поводу ехт4 точно не скажу, но у ехт3 это зависит от объема диска (нелинейно) и на обычном винте гиг на 500 суперблоков будет за далеко за десяток. Но толку то от этого? это как в свое время гнались в процах за гигагерцами - а потом на смену пням пришли коре дуо и заткнули их (даже если сравнивать пень 3 ггц против одного ядра дуо 2,2 ггц). И в нашем случае - суперблоков до.уя, а толку мало в плане практической надежности и в добавок получаем дополнительные тормоза для и без того медленной фс.

anonymous
()
Ответ на: комментарий от anonymous

>при вендовой скорости 30

Это если с горы при попутном ветре :) Слышали такую вещь, как фрагментация. А я слышу постоянно. Звучит: «Кря-кря-кря» при любом обращении к диску. Причём, от дисков с нтфс-ом. ФС оффтопа - одно из её самых слабых мест. Кричали бы про стабильность АПИ или большое колл-во вареза - был бы профит.

И что вендотроллям нужно на ЛОРе. Я же на винфак не лезу. Мне там не интересно.

anonymous
()
Ответ на: комментарий от anonymous

> NTFS - вот это поистине неубиваемая файловая система. Имеет журнал и ДВЕ таблицы файлов, с которыми работает непосредственно на винте.

Внезапно, в FAT-е тоже ДВЕ копии FAT-таблицы. А в ext-ах суперблоков вообще несчесть.

Проблема NTFS-а - ее тяжелое наследие в виде FAT и HPFS. NTFS работает, но работает настолько паршиво... Ее никогда нельзя заполнять до конца, иначе потом, даже если освободить место, начнется дикая фрагментация MFT и тормоза при любых операциях чтения и записи. А далеко не любой дефрагментатор умеет дефрагментировать MFT. Вообще, если в NTFS хоть раз запустить дефрагментатор, то приходится запускать его постоянно, иначе система будет деградировать на глазах, и загрузка за три минуты будет казаться быстрой.

Боюсь что на линуксе досих-пор нет более надежной файловой системы чем NTFS для Винды.

По сравнению с NTFS почти все линуксовые системы - образец скорости и стабильности. К ним никто не пишет дефрагментаторов, они никому не нужны - система НЕ ФРАГМЕНТИРУЕТСЯ. Да, чудес не бывает, рано или поздно, если забить все место, файлы начнут состоять из нескольких фрагментов. Но на скорость и надежность это не влияет.

В ext-ах нет MFT, который находится в одном конце диска, метаданных в другом и самих данных о файле в третьем - и данные и метаданные находятся рядом, не приходится прыгать по всему диску чтобы их читать. Даже если случится непоправимое, и шальной бед-блок уничтожит начало в группе блоков - только данные этой группы будут утеряны, и то не полностью. А на остальных группах это вообще не скажется.

Утверждаю из собственного опыта.

Угу. Недавно вот слетел MBR на винте, где были винда и линух - добрый пользователь ошибся диском, когда делал себе загрузочную флешку. Testdisk-ом удалось найти разделы. Линуху переустановили груб и он заработал. Винду восстановить не удалось - не грузилось, не монтировалось, забили, переустановить проще.

anonymous
()
Ответ на: комментарий от anonymous

>Слышали такую вещь, как фрагментация

собственно, 10 - это когда роутер качал всю ночь двухслойный двд с файлообменника в 1 поток на практически пустой винт. Если брать ситуацию параллельной скачки 4-х файлов - то тогда скорость колеблется от 7 до 8. Я ваще давно бы на фат32 перевел винт роутера (и одно время сидел на этой фс - замечательно ночные загрузки потом на нативной ведне копировались 25-30м) - но ограничение в 4гб для меня существенно

и еще по поводу дефрагментации - у линуха ехт4 также дефрагментируется, однако если вендой активно пользуются и постоянно идет запись/стирание фильмов, музыки, вареза, то у линуха в 95% случаев это еле заметная работа с файлами (все таки венда «для жизни», а линух - «для настройки») - разумеется, тут и фрагментация будет минимальной. На худой конец у венды хоть дефрагментатор есть более-менее вменяемый, а если ехт4 сильно фрагментируется - то веселая жизнь обеспечена

anonymous
()
Ответ на: комментарий от anonymous

>А в ext-ах суперблоков вообще несчесть.

а толку? по факту, проблем с ехт явно больше при ресетах/сбросе питания, чем на нтфс. Вы хоть еще в 10 раз увеличите количество суперблоков - ничего, кроме доп. тормозов не получите

начнется дикая фрагментация MFT

да, начнется - но ее легко избежать - всегда на свежих винтах заполняю мфт на 100-1000 тыс пустых файлов, затем удаляю их - и вуаля - у нас мфт имеет, как положено, всего 2 фрагмента и туеву хучу свободных ячеек для файлов. Вот тока давай ща не будешь спорить со мной, что это не срабатывает, ок?

Вообще, если в NTFS хоть раз запустить дефрагментатор, то приходится запускать его постоянно

обоснование? потому что гладиолус?

По сравнению с NTFS почти все линуксовые системы - образец скорости и стабильности

я плакалъ

К ним никто не пишет дефрагментаторов, они никому не нужны - система НЕ ФРАГМЕНТИРУЕТСЯ

я рыдалъ... почитай еще один мой пост выше - и сделай вывод, что малая фрагментация - это просто следствие вялотекущей работы с диском

В ext-ах нет MFT, который находится в одном конце диска, метаданных в другом и самих данных о файле в третьем - и данные и метаданные находятся рядом, не приходится прыгать по всему диску чтобы их читать

марш читать доки по устройству нтфс!

Винду восстановить не удалось

как в анекдоте - доктор сказал в морг- значит в морг! зы - в этой ситуации был не 1, а 2 кривых юзверя - первый - кто снес мбр, а второй - кто не смог восстановить

anonymous
()
Ответ на: комментарий от KRoN73

а так фат32 надёжней


Я попозже продолжу. Когда из под стола вылезу. Или это такой тонкий троллинг? ;)


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

Это практика, пруфы могут говорить что угодно, у железа своё мнение.

Napilnik ★★★★★
()
Ответ на: комментарий от wintrolls

>Много раз пропадало питание, за это время не потерялось ничего.

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

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

>На фате - перебил реестр вручную и благополучно загрузился. На нтфс - перебил реестр вручную и вероятность что это спасёт систему в несколько раз ниже чем на фате

ЧТО ЗА БРЕД? зы - господа администраторы, просьба для зарегеных юзеров ввести обязательную капчу на запись коммента - чтобы сильно подвыпившие юзвери не могли писать бред

anonymous
()
Ответ на: комментарий от anonymous

>единственное, когда данные потеряются - это если начнут массово сыпаться сектора на харде - так что попроси у мамки денег и поменяй уже свой гиговый хдд 10летней давности

Ты просто спец!

опять же к мамке за баблом на апгрейд - возьми хотя бы gf5200 - ща за 200-300 рублей ее тебе скинут - если даже не даром

Ну ты крут, наверно экстрасенс, чинишь компы по фотографиям. Видуха там не причём, материнка не совсем стабильна при старте, слишком много всего на ней смонтировано, но для десктопа сойдёт, не сервер за 1000 км.

Napilnik ★★★★★
()
Ответ на: комментарий от KRoN73

>Я в своих тестах не нашёл её преимуществ по этому параметру. Это просто очень быстрая на чтении ФС с дефрагментатором. Стать идеальной ей мешает чудовищный фэйл на удалении файлов. Так что, когда система в R/O или хотя бы без удаления - ФС великолепная. Как только в системе что-то часто удаляется - это уже нужно ext4 ставить.

Хм, по моим наблюдениям как раз наоборот, на удалении больших файлов XFS работает лучше других систем. На нулевой, только что созданной FS - ext3 удаляет 18-гиговый файл где-то полминуты, reiserfs - 8 секунд, ext4 пару секунд, а XFS - мгновенно (десятые или сотые доли секунды). Правда, если система сильно фрагментирована, время удаления сильно растет.

Вот при работе с кучей мелких файлов XFS очень сильно тормозит, ядро на разделе XFS у меня собиралось чуть ли не вдвое медленнее чем на reiser (а я еще удивлялся, почему на десктопе i7 и на файлопомойном сервере на семпроне время сборки так мало отличается - а все уперлось в скорость ввода-вывода)

zsh
()
Ответ на: комментарий от anonymous

>Чуть что происходит и ФАТУ обычно приходит пп-ц.

Это как нужно постараться чтобы грохнуть примитивную и простую систему. Ты не про дискеты сейчас говоришь? Некритичные баги типа потерянных файлов не приводят к краху фат32.

NTFS - вот это поистине неубиваемая файловая система. Имеет журнал и ДВЕ таблицы файлов, с которыми работает непосредственно на винте. Причем работает не с двумя таблицами сразу, а поочереди. В итоге, если что-то происходит, имея журнал и две таблицы с разными записями, чекдиск правит ошибки на ура.

Неа, как раз маздайная система не всегда может восстановить систему на нтфс, а времени на это жрёт ооочень много. Сколько бы таблиц не было, если они не идеально продуманы, ось на фс можно угробить. Если ты не в курсе, электричество вдали от областных центров глючит чаще и сильнее.

Боюсь что на линуксе досих-пор нет более надежной файловой системы чем NTFS для Винды. Утверждаю из собственного опыта.

Ехт ext 2, 3 и 4 вполне нормальные, а другими линуксовыми я пока и не пользовался, устраивали. Или может, для надёжной работы ntfs, с ней должен работать линукс ;)

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

>И после прохода чекдиска все файлы целы(не считая крайнередких, единичных случаев). Всеж, с баблом мелкософта, написать ФС(или купить) не составляет труда.

Ну да, знаем, целиком использовать сохранённую копию реестра принципы не позволяют, потому, если текущие 5 файлов реестра повреждены слишком сильно, штатные средства восстановления ничего толком не починят. А в линуксе админу можно всё.

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

>ЧТО ЗА БРЕД? зы - господа администраторы, просьба для зарегеных юзеров ввести обязательную капчу на запись коммента - чтобы сильно подвыпившие юзвери не могли писать бред

Что здесь делают технически неграмотные пользователи?

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

>> К ним никто не пишет дефрагментаторов, они никому не нужны - система НЕ ФРАГМЕНТИРУЕТСЯ.
Еще раз, для чего в Ext4 написали дефрагментатор? И попутный вопрос: как выполнить дефрагментацию на ReiserFS?

система НЕ ФРАГМЕНТИРУЕТСЯ.

если забить все место, файлы начнут состоять из нескольких фрагментов.


Но на скорость и надежность это не влияет.


Взаимоисключающие параграфы.

Винду восстановить не удалось - не грузилось, не монтировалось, забили, переустановить проще.

Если бы пользователь вместо виндового раздела указал линуксовый то все бы просто так и сразу восстановилось? Не смешите.
И причем тут надежность?

wintrolls ☆☆
()
Ответ на: комментарий от anonymous

>> но ограничение в 4гб для меня существенно
Если линуксовый драйвер уже допилили для rw, то попробуй exFAT.

wintrolls ☆☆
()
Ответ на: комментарий от Napilnik

>> Некритичные баги типа потерянных файлов
Т.е. на сохранность данных в файлах на файловой системе, которая и предназначена для хранения этих самых файлов нам пофигу.

ось на фс можно угробить.

Любую ось на любой фс можно угробить, это зависит от того как ей пользоваться.

wintrolls ☆☆
()
Ответ на: комментарий от Napilnik

>> Что здесь делают технически неграмотные пользователи?
Очень хороший вопрос. Свою грамотность ты уже проявил.

wintrolls ☆☆
()
Ответ на: комментарий от anonymous

>> Слышали такую вещь, как фрагментация.
Слышали, знаем. Разработчики Ext4 даже дефрагментатор запилили для борьбы с ней.

Я же на винфак не лезу. Мне там не интересно.

А мне там скучно. Хочется расширить свой кругозор.

wintrolls ☆☆
()
Ответ на: комментарий от wintrolls

>Т.е. на сохранность данных в файлах на файловой системе, которая и предназначена для хранения этих самых файлов нам пофигу.

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

Napilnik ★★★★★
()
Ответ на: комментарий от wintrolls

>Очень хороший вопрос. Свою грамотность ты уже проявил.

Я описывал технологии которые работают, а то что ты их ниасилил, так это твои личные проблемы.

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

>Это если с горы при попутном ветре :)

И это кстати еще не придел. И не надо про фрагментацию на НТФС - е. Про нее говорят так, как будто на других ФС ее нет. Между прочим, есть один простой фокус, который позволяет НТФС-у работать шустро и без сильной и излишней фрагментации. Дело в том, что изначально под нужды MFT резервируется n-ое количество места. А при заполнении диска на 90%, от этого места зарезервированого места откусывается половина. В итоге получаем фрагментированый MFT, размазанный по всему диску. Мало кто эту особенность знает, но очень много кто ею пренибрегает. А потом жалуются, что у них все тормозит. А фокус собственно в том, чтобы не заполнять диск на 90%. И все будет хорошо.

Звучит: «Кря-кря-кря» при любом обращении к диску.

Звучит как и любая другая журналируемая ФС, с файловой таблицей на винте, не надо приувеличивать.

И что вендотроллям нужно на ЛОРе.

Где вы увидели вендотролей. Разговор сам собой перешел на обсуждение ФС, что не удивительно, так как топик про тестирование ФС. А НТФС - хорошая ФС, поэтому ее тоже вспомнили. А с этим изречением несогласные - обычно люди к ней отношение мало имеющие.

Внезапно, в FAT-е тоже ДВЕ копии FAT-таблицы. А в ext-ах суперблоков >вообще несчесть.

Да, тока количество != качество.

если в NTFS хоть раз запустить дефрагментатор, то приходится >запускать его постоянно

Не все дефрагментаторы одинакого полезны. И опять же, как будто на других линуксовых ФС, запускать дефрагментаторы(если его успели сделать) нужно тока один раз в жизни. Да и это особенность ФС, орентированная на то, чтобы при возникновении внештатной ситуации во время дефрагментации(выключили свет и подобное) - инфа осталась жива. Если не знаете о чем говорите, хоть в интернете почитайте о том как НТФС работает и почиму.

По сравнению с NTFS почти все линуксовые системы - образец скорости >и стабильности

Очень смелое заявление.

К ним никто не пишет дефрагментаторов, они никому не нужны - система >НЕ ФРАГМЕНТИРУЕТСЯ

Ну-да. Сравните интенсивность файлового обмена на Винде(игрушки, новый софт и прочее) и повторите такую-же интенсивность на линуксе и удивляйтесь. Добавлю еще вот что - вы /home монтируете туда-же куда и корень? Так и в Винде перенесите профиль пользователя на соседний раздел. А вот потом и сравнивайте. Меня искренне умиляют подобные фанатские высказывания, имеющие малое отношение к реальности. Вы в линуксе делаете все по уму? Вот и в Винде сделайте все по уму, а уже потом сравнивайте.

anonymous
()

>Угу. Недавно вот слетел MBR на винте, где были винда и линух

Супер. Вы бы сначала восстановили mbr виндовой утилитой, а уже потом возвращали grub на место. Тогда бы все заработало - и линух и винда. А так, вы подняли линух и удивляетесь, почиму-же винда не поднялась автоматом. А с чего-бы? Когда вы поднимаете винду, у вас линукс автоматом не поднимается, зачем надеятся на обратное. И кстати, после перезаписи mbr - разделы не теряются. MBR - это главная загрузочная запись. К разделам она прямого отношения не имеет. Может вопрос в компитенции, а не в винде? Если вы знаете линукс это != вы знаете винду.

не монтировалось, забили, переустановить проще

Излюбленное действие новичков в винде - когда винда не работает, ее надо переустановить. Хотя винда очень успешно имеет свойство чиниться без всяких перестановок.

однако если вендой активно пользуются и постоянно идет >запись/стирание фильмов, музыки, вареза, то у линуха в 95% случаев >это еле заметная работа с файлами

Очень немногие понимают этот простой факт.

обоснование? потому что гладиолус?

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

На фате - перебил реестр вручную и благополучно загрузился.

??? Причем тут ФС и реестр, где связь?

Это практика, пруфы могут говорить что угодно, у железа своё мнение

Да.... И мнение железа кардинально отличается от вашего. Могу предложить простой эксперимент. Возьмите флэшку, отформатируйте ее в ФАТ32, накидайте в нее файлов, штатно вытащите, вставьте снова, начните кидать еще файлов и в момент копирования резко выдергивайте из компа. Повторите последний фаг раза 3 и если даже после этого ФАТ32 на флэшке выжил - проверьте ее чекдиском. Затем проделайте все тоже самое, тока отформатируйте флэшку в НТФС. А затем сравните полученный результат. И таких экспериментов я могу придумать еще два вагона. Вы утверждаете того, чего не занете.

Наверно в вашем городе электрооборудование хорошее, а у людей - >попрыгало напряжение и неназываемая ос сдохла.

Вопрос случая. Чаще на самом деле проносит, а если и не проносит - вставтье установочный диск винды в привод, загрузитесь в консоль восстановления и запустите чекдиск. Кстати, ФС в линуксе ведут себя как-то по другому и лучше, в подобных случаях?

anonymous
()

>не приводят к краху фат32

Да-ну? Лучшая перспектива, которая светит на Фате32 это куча папок типа «FOUND», а в хучшем - ФАТ32 придется востанавливать HEX редактором и то, если повезет и квалификация позволяет. Попробуй эксперимент, который я описал выше - глядишь и сменится точка зрения.

Если ты не в курсе, электричество вдали от областных центров глючит >чаще и сильнее.

Вкурсе, но поставя линукс - меньше ФС падать не будет.

Или может, для надёжной работы ntfs, с ней должен работать линукс ;)

Да, было бы надежнее. Винда при загрузке гораздо больше операций на запись делает. Жаль что линуксу НТФС в качестве основной ФС никто не даст.

Ну да, знаем, целиком использовать сохранённую копию реестра >принципы не позволяют

Поставль что-нибудь по свежее чем Windows XP и посмотри на то, что твориться у нее в папке config. Кстати, даже если у тебя повреждены сразу все кусты реестра - даже тогда систему с очень большой долей вероятности можно восстановить (если криворукий IT-шник до этого в ней не лазил и не «Оптимизировал»).

anonymous
()
Ответ на: комментарий от Napilnik

>материнка не совсем стабильна при старте, слишком много всего на ней смонтировано

куле, логично! я всегда знал, что, к примеру, нельзя занимать все слоты оперативы и пси - ато глючить будет - очень рад, что аналитики ЛОРа подтвердили мою точку зрения

anonymous
()
Ответ на: комментарий от Napilnik

>а времени на это жрёт ооочень много

вот скока работаю с нтфс, только сегодня аналитики с ЛОРа начали открывать мне глаза на правду. Даже общие спецификации нтфс-а в ранних постах треда уже опровергли.

anonymous
()
Ответ на: комментарий от anonymous

>я всегда знал, что, к примеру, нельзя занимать все слоты оперативы и >пси - ато глючить будет - очень рад, что аналитики ЛОРа подтвердили >мою точку зрения

Вы бредите? Занятость слотов под оперативу, шины PCI и подобное - не сколько не вляет на стабильность. Если при сильной загрузке слотов что-то глючит, это может быть проблема БП, матери впринцыпе, а так-же класические проблемы с оперативой(не связаны с загрузкой слотов) и несовместимостью железа. И люди, которые считают что занято много слотов = глюки - вообще впринцыпе не могут адекватно коментировать вопросы и статьи, в которых они ничего не знают(так, нахватались у соседей или получили единичный глюк и вот весь их опыт). А мы тут про ФС говорим, когда народ банальных вещей не знает.

Итог - повышайте свои знания и квалификацию, перед тем как утверждать что одна ФС лучше другой, потому что «лучшей» ФС меньше букв в названии, школьники мать вашу.

Могу так-же добавить до кучи, что опыт, полученный в результате эксплуатации домашнего компа, да даже эксплуатации 20ти компов - не опыт господа, не льстите себе.

anonymous
()
Ответ на: комментарий от anonymous

>Даже общие спецификации нтфс-а в ранних постах треда уже опровергли

А можно подробнее на этом моменте?

anonymous
()
Ответ на: комментарий от anonymous

>А можно подробнее на этом моменте?

«В ext-ах нет MFT, который находится в одном конце диска, метаданных в другом и самих данных о файле в третьем - и данные и метаданные находятся рядом, не приходится прыгать по всему диску чтобы их читать.»

этого хватит? мфт при инициализации (форматировании) диска имеет 2 копии - в начале и центре раздела. записи о файлах же будут располагаться в «третьем» месте только при сильной фрагментации + высоком % использовании диска, однако этого можно избежать - как - указал выше в постах.

Короче, народ - не и.ите моск - читайте мануалы по нтфс и потом не говорите - «а нтфс поддерживает уже ресеты» и прочую лабуду вроде вышеприведенной цитаты

anonymous
()
Ответ на: комментарий от anonymous

OFX:

читайте мануалы по нтфс и потом надейтесь, что венда работает с ntfs так как в них написано, а не так, как со всем остальным в этой системе

Hokum ☆☆☆☆
()
Ответ на: комментарий от Napilnik

>> Я описывал технологии которые работают, а то что ты их ниасилил, так это твои личные проблемы.

Под систему её пихать имело смысл только там где нужны пароли на каталоги

а так фат32 надёжней и практичней


лечится ресетом


ext3 и 4 много раз ресетил



Да, эти „технологии” я явно не осилил.

wintrolls ☆☆
()
Ответ на: комментарий от Napilnik

>Можешь думать что угодно, написанное в официальных книжках не всегда полностью соответствует действительности

Ясно. Троллинг.

KRoN73 ★★★★★
()
Ответ на: комментарий от zsh

>Жалко нет тестов рейзер4, думаю она бы себя показала на мелких файлах получше чем бтрфс с ехт4.

reiser4 в целом себя ведёт на уровне ext4. Немного быстрее и компактнее, но не принципиально. btrfs пока им заметно проигрывает.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Плоховато. Пару раз отключили электричество - винекапец пришел.

Как-то странно вы её готовите... Я однажды mobile rack с NTFS, забыв отмонтировать поменял на другой винт. Даже с другой геометрией. И начал работать с ним. Когда вывалилась ошибка - понял и схватился за голову. На новом винте оказался прописан каталог от старого... Ничего, chkdsk всё восстановил кроме тех нескольких файлов, что пострадали при перезаписывании :)

...

NTFS я использовал, начиная с Windows 3.11 на многих десятках (а, может, и сотнях - не считал точно, но сотни машинолет - уже точно) машин в самых жёстких условиях (тупые юзеры, постоянно жмущие reset'ы, отключения питания и т.п.). И ни разу она у меня не падала.

Вот FAT32 - да, эта зараза падала и падает очень часто.

Один раз (на ~5..7 машинолет эксплуатации) полностью невосстановимо падала ext3 и несколько раз на ext3 при отрубании питания терялись файлы.

Были зануления файлов при отрубании питания на XFS (но это у неё в генах, ей так положено).

Ни разу не падали ReiserFS (что-то около 6..8 машинолет) и ext4 (3-4 машино-года).

По остальным FS статистики использования убедительной мало (reiser4 около полугода, не падала, но к концу эксплуатации нещадно тормозила, остальные - совсем эпизодически).

KRoN73 ★★★★★
()
Ответ на: комментарий от Hokum

>А в тестах бывает и эпик вины даёт

Ну, у меня-то по btrfs - тоже из тестов данные. Только тесты «приближённые к реальным задачам» :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.