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

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

Отучаемся говорить за всех.

У подруги компьютер используется для просмотра фильмов. Качаются они постоянно. И забиваются разными фильмами про золушек постоянно и под завязку. Используется фрагментарный метод скачивания (когда файл увеличивается по мере загрузки).

Скорость работы диска такая же, как при создании раздела. Попробуйте повторить это в своей любимой системе.

Я уже молчу про такие вкусности, как lvm и программный raid...

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

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

И это линуксоидов называют красноглазиками! Я просто создаю ФС и забываю о том, что она есть. УМВР. Без обслуживания, тюнинга, хаков и прочего.

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

>NTFS я использовал, начиная с Windows 3.11

помоему нтфс стала впервые поддерживаться в линейке нт

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

>У подруги компьютер используется для просмотра фильмов

смотри - фильм, 1400мб, 100 фрагментов - это примерно 1,4мб фрагмент - то есть где то минута фильма. Ничего страшного, раз в минуту винт может сделать доп. движение. Вот когда у нее будет еще полно музла и пикчурсов и она попытается скопировать гиг так 300 этой ерунды на другой винт - вот тогда и поговорим про «такую же» скорость

Используется фрагментарный метод скачивания

может она еще и торренты скачивает «фрагментарно»? п.здеть - не мешки ворочать. Хотя если качать по 1 фильму за раз, браузером - то фрагментов будет мало

Скорость работы диска такая же, как при создании раздела

как скорость то оценивали? или вас, линуксоидов, хлебом не корми - дай посчитать быстродействие фс? было бы смешно, если файл 1,4 гб при 100 фрагментах проигрывался с рывками из за того, что головке винта приходится лишний раз в минуту перепозиционироваться

Я уже молчу про такие вкусности, как lvm и программный raid...

программный рейд - это вкусности? ппц ты специалист.... для справки (и для тех, кто отстал от жизни лет так на 5) - большинство современных матерей, даже дешевых, позволяют сделать программный рейд в венде - скачиваем утилиту с сайта интела - и вуаля!

И это линуксоидов называют красноглазиками! Я просто создаю ФС и забываю о том, что она есть. УМВР. Без обслуживания, тюнинга, хаков и прочего.

винт то поди не каждый день форматируют, не? а написание скрипта для этой цели занимает порядка 5 минут на ruby,python и т.д. - сам процесс на 1000 тыс. файлов занимает порядка 15 минут - я уж смогу выделить раз в пару лет эти 20 минут... а по поводу «просто создаю фс» - вот также «просто» твоя ехт ляжет при случайном сбросе питания или ресете. К тому же, суммарное время от выйгрыша в скорости нтфс относительно ехт даже при минимальной активности с диском уж явно превзойдет эти мои 20 минут в первую же неделю малоактивного юзания

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

Ещё покормлю.

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

1. Пишется «преувеличивать» (любой браузер, кроме ie имеет проверку орфографии :) ). 2. А вы сами сравните, как ведут себя сильнонагруженные ФС с малым количеством места.

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

1. «почему» - use aspell, Luke. 2. Не все полезны. В венде нужен постоянно, работает долго, ничего запускать в это время нельзя, результат ощутим короткое время. В Линуксе не нужен в принципе. 3. А если дефрагментатор не используется, а инфа осталась жива - не считается? :) 4. В интеренете много маркетинга (и мс тратит на него больше, чем Линус). Много субъективных оценок (вы же пишите это в интеренете). Я сам тестил: ext2, ext3, ext4, reiser3fs, reiser4, xfs, fat32, ntfs. Или моего опыта для моих выводов недостаточно?

повторите такую-же интенсивность на линуксе и удивляйтесь.

А ты погоняй, в несколько потоков, 30Gb exr файлов по 1.5Mb за ночь и удивишься!

Добавлю еще вот что - вы /home монтируете туда-же куда и корень? Так и в Винде перенесите профиль пользователя на соседний раздел.

А ФС - это часть системы. Если в Линуксе всё организованно правильно - это плюс. А ещё у вас есть файл подкачки, который постоянно дефрагментирует системный раздел.

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

>помоему нтфс стала впервые поддерживаться в линейке нт

Опечатка :) Конечно, имелась в виду NT 3.51 :)

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

перехвачу хавчик у того коллеги - анонимуса

любой браузер, кроме ie имеет проверку орфографии

1. не везде словари по умолчанию включены 2. не везде есть русский словарь искаропке

В венде нужен постоянно

скажем так - нужен переодически

ничего запускать в это время нельзя

и дышать тоже

результат ощутим короткое время

зависит от активности юзания диска. Системный раздел с устоявшимся набором софта фрагментировать можно раз в полгода при крупном обновлении ПО

В Линуксе не нужен в принципе

1. зачем же тогда дефрагментатор для ехт писали? 2. если вся работа, как обычно, это правка конфигов - то да, не нужен

Много субъективных оценок

согласен. Взять тот же анализ стоимости спо против мс для школ. Однако, хорошее качество фс нтфс, понимают многие не-фанатики

Или моего опыта для моих выводов недостаточно?

а как нтфс то тестил? небось на линухе? с его полукривым нтфс3ж? прям как в анекдоте «Басков плохо и фальшиво поет - а ты его слышал? - нет, мне его гоги напел»

А ты погоняй, в несколько потоков, 30Gb exr файлов по 1.5Mb за ночь и удивишься

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

в Линуксе всё организованно правильно

даже сам торвальдс признавал, что линух движется в каком то непонятном направлении - нет централизованной идеи развития

а поводу «организованности» фс линуха - такое запросто можно сделать и в венде - «подключить том как папку» - вот только никто это не юзает - ибо неудобен сам факт такой иерархии

А ещё у вас есть файл подкачки, который постоянно дефрагментирует системный раздел

ВО ГЕНИЙ ТО! Наводящие вопросы: 1. когда начинается разрастание файла подкачки? 2. скока оперативы в современных компах? 3. сколько нужно оперативы для комфортной работы с осью? давай, гугли поскорее

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

Поэтому и использую её на домашнем NAS'e для HD-видео. А вот фотки, музыку лучше, наверное вести на ext4 - диск. Для закачек, думаю, можно попробовать ext2 - ибо ничего ценного - чисто мелким перевалочным пунктом на 1-1,5 тб использовать.

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

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

Почитай немного для самообразования чтобы не продавливать ахинею собственным авторитетом, а тот ведь не железный http://admin-dm.livejournal.com/21337.html Копипаста новости довольно свежая, народ использует.

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

> И не надо про фрагментацию на НТФС - е. Про нее говорят так, как будто на других ФС ее нет.

Да. Именно про это и речь! На linux-fs ее нет!

> есть один простой фокус, который позволяет НТФС-у работать шустро и без сильной и излишней фрагментации. Дело в том, что изначально под нужды MFT резервируется n-ое количество места.

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

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

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

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

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

> Не все дефрагментаторы одинакого полезны.

Тоже есть такое дело. И найти хороший дефрагментатор для NTFS непросто. Еще один минус NTFS.

> хоть в интернете почитайте о том как НТФС работает и почиму.

Давайте читать вместе? Особенности дефрагментации NTFS

> Сравните интенсивность файлового обмена на Винде и повторите такую-же интенсивность на линуксе и удивляйтесь.

Уже много лет [не] удивляюсь. На винде скорость загрузки системы сразу после установки - меньше 30 секунд, а через пол года идет на минуты. И это только при мелких системных апдейтах, да обновлении софта (офис, браузер, почтовик, ну и те же игрушки). В линухе она за пять лет существования файловой системы с каждым апдейтом все быстрее и быстрее. :)

> вы /home монтируете туда-же куда и корень?

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

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

> Вы бы сначала восстановили mbr виндовой утилитой, а уже потом возвращали grub на место. Тогда бы все заработало - и линух и винда.

Бред. :) Виндовый MBR не умеет грузит линух. Да и как его восстановить, если даже списка разделов не осталось? Разделы были восстановлены testdisk-ом. Он - линуховый. Какая виндовая утилита умеет делать то же самое? Затем в MBR был установлен груб, который там и был раньше. После чего линух загрузился. Смонтированная в ro NTFS в линухе показывала красные знаки вопросов вместо файлов и каталогов. Попытка сделать что-то с разделом в винде выдавала нечто вроде «диск имеет неизвестный формат». Еще варианты?

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

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

Время на починку значительно превышало время переустановки. Это в линухе на восстановление ушло 10 минут, а в винде... Зачем заниматься мазохизмом?

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

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

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

Кто-то из нас двоих тупит, и это - не я. :) Для того, чтобы прочитать содержимое файла в NTFS надо: найти в каталоге ссылку на этот файл (РАЗ), прочитать в MFT информацию о том, где лежат данные файла (ДВА) и затем прочитать сами данные (ТРИ). Обычно все они лежат в разных частях диска. И это - БЕЗ ФРАГМЕНТАЦИИ. С фрагментацией будет хуже.

Кстати. В первых же нагугленных в и-нете ссылках написано, что копия MFT таки только одна. Две копии только у ссылки на метафайлы MFT и журнала. Но сами метафайлы хранятся в единственном экземпляре. Если это так, то NTFS еще менее надежна чем FAT, там хоть было две копии FAT-таблицы. Гугл врет?

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

>Да. Именно про это и речь! На linux-fs ее нет!

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

Давайте мы выкинем 10% места на нашем диске, чтобы винда не тормозила

вопрос на засыпку - имеем 1тб винт - форматируем его в ехт3. сколько места займет сама ехт? нтфс займет порядка 50 метров... а по поводу метаданных для файлов - и в ехт и в нтфс место будет отниматься

Вот так виндоюзеры и живут - с костылями из-за кривых ФС

однозначно, это не фанатизм - это тупость

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

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

Тоже есть такое дело. И найти хороший дефрагментатор для NTFS непросто. Еще один минус NTFS

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

Давайте читать вместе?

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

В линухе она за пять лет существования файловой системы с каждым апдейтом все быстрее и быстрее

это не лечится....

Да.

это финишь! с мягким знаком! Одно дело, красноглазить и не разбираться в венде хая ее на всех углах, другое дело - не разбираться ни в линухе, ни в венде

Там и игрушки

по этой фразе понятно, что перед нами - вендузятник, который ее ниасилил и пытается пересеть на линух - но там тоже плоховато получается - вот и решил он потроллить на ЛОРе

что криворукие программеры одной микро-корпорации не смогли создать нормальную ФС и драйвера для нее

судя по всему твоему посту, у тебя есть только один выход - одолжи у знакомого мотоцикл, одень шлем задом наперед - и в путь дорожку....

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

>Почитай немного для самообразования

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

...

Мне читать ничего не нужно, мне хватает собственного опыта работы с FAT32 в течении последних 15-ти лет.

Утверждать, что эта FS хоть сколь нибудь минимально надёжна может только или дебил, или тролль :)

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

>Бред. :) Виндовый MBR не умеет грузит линух

А чей-то MBR, разве, может?

...

Мне когда-то хватало штатного виндового бутлоадера для загрузки Linux :)

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

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

Еще раз, для чего в Ext4 написали дефрагментатор?

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

И попутный вопрос: как выполнить дефрагментацию на ReiserFS?

Не нужна она. Для btrfs или reiser4 - да, там нужна. Потому что фича copy-on-write по определению означает высокую фрагментацию. А для старых ФС, таких как ext3 и reiserfs, дефрагментаторы не нужны. Драйвер написан достаточно умно и без этого. Их можно написать, но они не прибавят производительности. По крайней мере мне не попадался ни один тест, который утверждал бы обратное.

Это в NTFS нужна дефрагментация. Там необходимость сделать систему, позволяющую конвертацию FAT->NTFS, плюс глупости, допущенные при проектировании, преумножились тупостями алгоритмов, используемых в драйвере файловой системы. Получившаяся система оказалась ужасна. Вот и пришлось придумывать костыль в виде дефрагментатора. Отсюда же и советы из области «создать и удалить стопиццот файлов, не заполнять больше чем на 80%»...

«В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили - NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю... Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально.»

Источник этой фразы я предлагаю загуглить самостоятельно. :)

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

> Ну хорошо, предположим, что нет фрагментации, то зачем тогда пишут дефрагментаоры под линуховые фс?

Потому их и не пишут. :) Подробности - на одно сообщение выше.

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

А гугль как раз говорит, что у них одна копия. Только две ссылки на ее расположение на диске. Врет?

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

>Может просто потому, что она позволяет его сделать?

ну да - народу заняться нечем, вот они и выдумывают себе работу. Даже если дефрагментатор не нужен, его нужно написать!

Получившаяся система оказалась ужасна.

в зеркало глянь - вот что получилось ужасно, фанатизм и красноглазие налицо. У нтфс один минус - фрагментация, но много плюсов - скорость, надежность, малая подверженность сбоям. Ради эксперимента, сделай копию файла в 1гб и копии 100 000 файлов по 10 кб на одном разделе с ехт, а затем на нтфс - и засеки время копирования. Будешь очень удивлен. И в завершении попробуй сделать то же самое еще раз, но выруби питание в середине операции.

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

>да, grub'овский может или lilo'вский

Тогда и виндовый может :) Grub не сидит целиком в MBR. Как и виндовый бутлоадер.

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

>> А для старых ФС, таких как ext3 и reiserfs, дефрагментаторы не нужны. Драйвер написан достаточно умно и без этого.

Вот и пришлось придумывать костыль в виде дефрагментатора.


> Еще раз, для чего в Ext4 написали дефрагментатор?

Может просто потому, что она позволяет его сделать?



Т.е. ты утверждаешь что старые ext3 и reiserfs „достаточно умные” и их не нужно дефрагментировать, а ext4, btrfs и reiser4 — говно, и поэтому к ним пишут костыли в виде дефрагментаторов? :)

Их можно написать, но они не прибавят производительности.

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

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

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

Какие же это недостатки? Слишком простые, как ext2? Или слишком быстрые? Или, может, благодаря tail-packing, слишком эффективно хранят файлы на диске?

В линухе она за пять лет существования файловой системы с каждым апдейтом все быстрее и быстрее

это не лечится....

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

Одно дело, красноглазить и не разбираться в венде хая ее на всех углах, другое дело - не разбираться ни в линухе, ни в венде

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

Там и игрушки

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

Да, настоящие линуксоиды суровы. Им неведомы прелести жизни. Они посвящают себя созерцанию консоли и в этом познают истину. :)

Надо все же отличать сервер от домашней машины. Дома человеку хочется отдохнуть и отвлечься от работы, заняться чем-то другим. А еще (о ужас!) есть дети, и они хотят играть.

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

> Когда я учился в школе, такого предмета еще не было :(.

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

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

По поводу ехт4 точно не скажу, но у ехт3 это зависит от объема диска (нелинейно) и на обычном винте гиг на 500 суперблоков будет за далеко за десяток.

Крис Касперски в своей книжке по восстановлению данных пишет, что реально используется порядка 5 суперблоков: «Ранние версии файловой системы ext2 создавали копии суперблоков в начале каждой группы блоков. Это приводило к большим потерям дискового пространства, поэтому позже количество резервных копий суперблока было уменьшено, и для их размещения были выделены группы блоков 0, 1, 3, 5 и 7».

Что изменилось при переходе на ext4?

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

> Т.е. ты утверждаешь что старые ext3 и reiserfs „достаточно умные” и их не нужно дефрагментировать, а ext4, btrfs и reiser4 — говно, и поэтому к ним пишут костыли в виде дефрагментаторов? :)

ext4 - нет, даже наоборот, delayed allocation для ext4 уменьшает фрагментацию по сравнению с ext3. Отличия между ext3 и ext4 больше в драйвере, чем в структуре файловой системы. Хотя из-за изменений в алгоритмах ext4 иногда бывает медленнее ext3 (гуглить переписку в LKML c Линусом на тему data=writeback), но это стараются исправить, и с фрагментацией это почти не связано. А в btrfs и reiser4 - да, дефрагментатор нужен обязательно, иначе со временем система начинает сильно тормозить.

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

А ты, очевидно не прогуливал, и знаешь? Может еще и сможешь подтвердить это ссылками на соответствующие тесты - как влияет фрагментация линукс-разделов на скорость файловых операций?

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

> ну да - народу заняться нечем, вот они и выдумывают себе работу. Даже если дефрагментатор не нужен, его нужно написать!

Так виндотролли же просят. Они пришли с винды, а там без дефрагментатора - никуда. Проще написать, чем объяснять каждому новому троллю, что она не нужна. К тому же для маркетинга и привлечения клиентов фраза «онлайн-дефрагментатор» звучит круто. И, наконец, от того, что его напишут, хуже все равно не будет. Так почему бы и не написать?

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

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

> Тогда и виндовый может :) Grub не сидит целиком в MBR. Как и виндовый бутлоадер.

Да, он может. Нужны небольшие шаманства, но действительно можно грузить груб из виндового NTLDR/BOOTMGR. Ядро - нельзя, но груб можно. Только для того, чтобы это сделать, винду надо сначала восстановить. А в том случае это оказалось не так просто.

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

>> как влияет фрагментация линукс-разделов на скорость файловых операций?
А причем тут линукс? У него какая-то своя, особенная фрагментация?

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

http://en.wikipedia.org/wiki/Ext3

Ъ:

While ext3 is more resistant to file fragmentation than the FAT filesystem, nonetheless ext3 filesystems can get fragmented over time or on specific usage patterns, like slowly-writing large files.[23][24] Consequently the successor to the ext3 filesystem, ext4, is planned to eventually include an online filesystem defragmentation utility[25], and currently supports extents (contiguous file regions).

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

Еще раз повторю свой вопрос - Вы можете обосновать влияние фрагментации в высоконагруженной системе на производительность? А Windows это будет, или Linux - дело десятое...

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

>Вы можете обосновать влияние фрагментации в высоконагруженной системе на производительность?

Много времени начинает уходить на позиционирование головок винта.

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

> Много времени начинает уходить на позиционирование головок винта.

Вот здесь я написал, почему, на мой взгляд, это утверждение справедливо только для однозадачной и (или) малонагруженной системы:

http://www.linux.org.ru/jump-message.jsp?msgid=5594213&cid=5608807

Хотелось бы услышать Ваши комментарии...

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

>Хотелось бы услышать Ваши комментарии...

Практика - лучший комментарий. Дефрагментация на запущенной системе ОЧЕНЬ сильно повышает быстродействие. И не важно, NTFS это, XFS или ext4.

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

>может она еще и торренты скачивает «фрагментарно»? п.здеть - не мешки ворочать. Хотя если качать по 1 фильму за раз, браузером - то фрагментов будет мало

Язык прикуси, быдло. Закачки идут из p2p сети со скоростью 10Мб/с в несколько потоков на забитый до отказа диск. До этого тем же самым занималась венда. Каждые несколько месяцев производительность дисковой подсистемы ощутимо подала (система, например, вдвое медленнее грузилась). Дефрагментация помогала не надолго.

программный рейд - это вкусности? ппц ты специалист.... для справки (и для тех, кто отстал от жизни лет так на 5) - большинство современных матерей, даже дешевых, позволяют сделать программный рейд в венде - скачиваем утилиту с сайта интела - и вуаля!

А сам пробовал так делать? Если нет, не стоит рот открывать.

винт то поди не каждый день форматируют

В Линуксе нет утилит форматирования :)

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

>1. не везде словари по умолчанию включены 2. не везде есть русский словарь искаропке

Таки словарь он не осилил, а доказывать с пеной у рта, что одна система лучше другой - может! Причём, вторую он никогда не видел :)

а как нтфс то тестил? небось на линухе? с его полукривым нтфс3ж? прям как в анекдоте «Басков плохо и фальшиво поет - а ты его слышал? - нет, мне его гоги напел»

К сожалению, Басков и правда плохо поёт. А в венде мне часто приходится сидеть. И о её проблемах знаю хорошо. Считаю, что слушать баскова и использовать венду вредно. От первого портится слух, от второго развивается дистрофия мозга. Эти проблемы нам надо решать сообща! Так прекратим же слушать бредятену и поставим нормальную систему. Тогда у нас всё получится!

Если вы это сделаете, у меня пропадёт необходимость отвечать на ваши вопросы, а у вас спорить со мной!

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

> Практика - лучший комментарий. Дефрагментация на запущенной системе ОЧЕНЬ сильно повышает быстродействие.

Мой опыт говорит, что разница практически не ощущается. 7 лет эксплуатировал RedHat9 в качестве довольно нагруженного почтового сервера, падения производительности не замечал. Рядом стоит терминальный сервер W2K3 на 40 пользователей - машине уже 3.5 года, ни разу никакой дефрагментации не проводилось. Падения производительности тоже нет. Все примеры, которые приводили в данном топике, касались в основном домашних систем, работающих фактически в однопользовательском режиме. Ну и практика, конечно, критерий истины :), но хотелось бы услышать и теоретическое обоснование. Потому что по логике получается, что фрагментация не должна ни на что влиять. Естественно, если машина под нагрузкой работает...

И не важно, NTFS это, XFS или ext4.

С этим согласен - тип файловой системы абсолютно не важен...

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

>7 лет эксплуатировал RedHat9 в качестве довольно нагруженного почтового сервера, падения производительности не замечал

А на сервере падение производительности много сложнее заметить :)

Речь о десктопе. Тут каждый десяток процентов чувствуется пятой точкой, а 50% падения приводит к «неимоверным тормозам».

Потому что по логике получается, что фрагментация не должна ни на что влиять


По логике она влияет на то, что винту приходится намного больше работать головкой. Особенно это заметно на многопоточном чтении.

Если мне память не изменяет, то многопоточное чтение мелочёвки из /usr с сильно фрагментированной системы в 2-3 раза меньше, чем с дефрагментированной. Но этот тест я давно проводил, уже не помню точно.

Зато «дефраг мувом» для /usr нередко повышает скорость запуска программ раза в два. А дефрагментация виндового диска способна совершенно неиграбельную из-за постоянных подгрузок игрушку превратить в очень плавную и красивую.

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

> Речь о десктопе. Тут каждый десяток процентов чувствуется пятой точкой, а 50% падения приводит к «неимоверным тормозам».

IMHO, в качестве десктопа современные машины практически простаивают... У меня до сих пор местами стоят машинки PI 200 Mhz c 96 MB RAM и ничего, народ работает и не жалуется. Это я к тому, что борьба за десяток процентов на десктопе, IMHO, смысла особого не имеет - мощности железа обычно избыточны. Но тут каждый сам решает, что ему важнее.

Возвращаясь к теме обсуждения, Вы согласны с выводом, что фрагментация начинает негативно сказываться только в условиях малого числа процессов, одновременно конкурирующих за IO? В случае же нормальной серверной нагрузки, разницы практически не будет?

Особенно это заметно на многопоточном чтении.

Вы не оговорились? IMHO, разница будет заметна на однопоточном чтении. На многопоточном чтении головки и так будут бегать у Вас от файла к файлу...

А на сервере падение производительности много сложнее заметить

IMHO, все ровно наоборот. Сервер за 7 лет эксплуатации вплотную приближается к пределу своих аппаратных возможностей и там каждые 5% начинают влиять на длину почтовых очередей. Десктопы на пределе практически никогда не эксплуатируют...

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

>Или слишком быстрые?

ты вообще понимаешь, с чем имеешь дело? или тебе сказали: линух лучше венды и все? фанатизм ни к чему хорошему не приведет, ведь в этом случае ты начинаешь забивать на факты и живешь своей религией

слишком эффективно хранят файлы на диске?

а здесь можно поподробнее - это что за характеристика фс «эффективность хранения файлов на диске»?

За 5 лет, которые линух живет на этом корне в каждом новом релизе система грузится все быстрее... это заслуга не файловой системы, а новых ядер...

отбросим этот маразм и посмотрим на это с другой стороны - по сути, за 5 лет любой мало-мальски нормальный спец меняет себе дома железо по полной. Ты, как я вижу, по крупному ничего не апгрейдил (то есть на том основании, что у тебя железо то же, а работает быстрее - ты сделал вывод о приросте скорости, ведь если бы ты сменил мать и проц с p4 на core quad то такое сравнение было не уместно, не?) - получается, что ты школота и сидишь у мамы на шее, сам к тому же еще не работаешь - с тобой все ясно ЗЫ - факт - с течением времени и выходом новых версий ПО система только тяжелеет (в среднем) - если 5 лет назад хватало всем 512 оперативы, то теперь меньше чем с гигом лучше не сидеть

Зачем мне на моей домашней машине (не на сервере) разделять /home и корень?

мда... ты еще /tmp и /var докинь в коренной раздел...

Надо все же отличать сервер от домашней машины. Дома человеку хочется отдохнуть и отвлечься от работы

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

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

>По идее самая большая фрагментация должна быть у пользователей gentoo, которые постоянно что-то компилируют

смотри - сколько места занимает система со всем ПО? ну 15 гиг от силы. какая нах дефрагментация при том, что объем винта несколько сотен гигов? а каталог /tmp на другом разделе? мы опять упираемся в то, что красноглазики не юзают всех возможностей для жизни, а тупо берут винт на 1 тб и ставят туда генту, которая занимает 10 гиг - и радуются (ах,да - они еще покупают жф480...)

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

>Закачки идут из p2p сети со скоростью 10Мб/с в несколько потоков на забитый до отказа диск

напомню, что большинство p2p клиентов сразу выделяют место на диске. имя твоего клиента ффстудию!

Каждые несколько месяцев производительность дисковой подсистемы ощутимо подала (система, например, вдвое медленнее грузилась)

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

А сам пробовал так делать? Если нет, не стоит рот открывать.

такой, к.ней, как программный рейд, лучше не заниматься. Поростешь, устроишься на работу в какую либо более-менее солидную фирму IT (хотя без блата ТЕБЯ туда не пустят) - вот и увидишь, что НИКТО не юзает программные рейды, только аппаратные с недешевыми контроллерами

В Линуксе нет утилит форматирования :)

это как наш прогноз погоды - за окном дождь - по радио передают: «без осадков, солнечная погода»

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

>и использовать венду вредно

разные инструменты пригодны для разных дел - а то, что ты сказал - фанатизм в чистом виде

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

> вот и увидишь, что НИКТО не юзает программные рейды, только аппаратные с недешевыми контроллерами

Вот только не надо рассказывать сказок.

В рекомендациях EMC по конфигурированию DMX-ов (надеюсь не надо объяснять что это такое ?) прямо открытым текстом сказано, что большие по размеру волюмы, от Tb и более, лучше собирать как раз программным Volume Manager-ом. На массиве нарезаются относительно небольшие volumes RAID 1+0 и например VxVm-ом собираются в страйп.

Причины: во первых это позволит разгрузить Channel Dirrector-ы и FC HBA на сервере (волюмы рекомендуется мапировать на разные Dir-ы или хотя бы на разные процессоры одного Dir-а), во вторых это связано с алгоритмами выделения кэша, которые дают больший эфект при наличии нескольких отдельных волюмов чем от одного большого.

Абсолютно то же самое можно сказать и про Hitachi и остальные массивы.

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

>IMHO, в качестве десктопа современные машины практически простаивают

Угу. Но не в момент запуска программ, о котором шла речь :)

...

Ещё очень сильно фрагментация сказывается при наличии фоновых p2p-раздач или компиляции в фоне на Gentoo.

В случае же нормальной серверной нагрузки, разницы практически не будет?


В случае сервера разница тоже будет. Но она будет меньше бросаться в глаза. Да, у меня на Gentoo-сервере запрос на обновление мира год назад обрабатывался за 6 секунд, а сейчас - уже за 10-15 сек. Но сервер обычно занят LAMP'ом, все нужные компоненты загружены в память и в этом случае, естественно, скорость дисковой подсистемы не критична.

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

Сервер за 7 лет эксплуатации вплотную приближается к пределу своих аппаратных возможностей и там каждые 5% начинают влиять на длину почтовых очередей


Сделайте дефрагментацию майлдиров. Эффект удивит :D

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

>По идее самая большая фрагментация должна быть у пользователей gentoo, которые постоянно что-то компилируют

/var обычно вообще у всех на отдельном разделе. А у пользователей Gentoo нередко отдельно вынесен даже /var/tmp/portage, в котором идёт компиляция. И не так уж редко - он вообще в tmpfs :)

...

Так что уровень фрагментации у пользователей Gentoo обычно не выше, чем у пользователей других систем.

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


Я измерял, хотя и в ином аспекте: http://balancer.ru/tech/forum/2008/06/t62136--proizvoditelnost-fajlovykh-sist...
Там получилось, что скорость компиляции вообще почти не зависит от файловой системы. Это при компиляции в один поток на ненагруженной системе. Все рабочие файлы, в итоге, кешируются, а при однопоточном линейном чтении на фоне общих затрат на компиляцию состояние файловой системы уже мало сказывается.

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

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

>а каталог /tmp на другом разделе?

/tmp, вообще, сегодня на всех системах модно ставить в tmpfs ;)

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

>напомню, что большинство p2p клиентов сразу выделяют место на диске. имя твоего клиента ффстудию!

rtorrent :)

но каким же надо быть красноглазиком, чтобы хранить систему и мультимедиа на одном разделе?


А пофиг. Когда они на разных разделах одного винта, то винту не приходится меньше работать головками. Спасёт только разнесение на разные винты.

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

>А пофиг. Когда они на разных разделах одного винта, то винту не приходится меньше работать головками. Спасёт только разнесение на разные винты.

собственно, это так, но что мы обычно делаем с мультимедиа? слушем (300кб.с), смотрим двд (1мбайт/с), качаем (1-3мбайт/с,10 в случае локалки) - такие скорости - 1- в принципе не имеют значения для загрузки системы, когда грузится ось и автозагрузка - ибо в этот момент никто еще ничего не делает, 2 - еле заметно сказываются на скорости работы системы. На практике имеем лишь тормоза, когда копируем кучу файлов гиг так на 10-100 и более между разделами или винтами либо архивируем/разархивируем папку на неск. гигов А поскольку я оспаривал фразу относительно замедления работы системы (загрузки), то тут вынесение системы в отдельный раздел очень обоснованно (точнее - логично, а смешивать систему и данные - это бред полнейший), но понятно, что для полного комфорта желательно иметь систему на отдельном винте

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

>такие скорости - 1- в принципе не имеют значения для загрузки системы

Когда дело доходит до практики - очень имеют :)

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

а теперь перечитай то, что ты написал и сделай вывод - почему рекомендуют программный рейд. Можно сделать то же самое, задействовав 2 и более аппаратных рейдов, но в этом случае цена на требуемое железо взлетит очень существенно (вспоминается сговор мс и интела, когда на 512 оперативы и дуо 1.6 ставили висту - и значок сертификации железа налепляли - а все почему? на.ер никому бы не была нужна виста, если бы в то время запросы отрезались на мнимальной конфигурации 2 гб, дуо 2,4, жф9600). Вот и тут рекомендации аналогичные.

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