Тестирование ФС именно при том, что физическая скорость никогда на самом деле не достигается при работе с файлами. hdparm -t читает всё подряд, не смотря на то какой это фаил или не фаил ... а вот когда я копирую самбой или с помощью мс то тут копирование идёт через механизмы ядра (драйверы файловых систем), я копирую не всё подряд, а нужные мне блоки данных, быть может кстати фрагментрованные (это для НТФС подходит, ехт3 как я понял не может быть фрагментирована в принципе). Так что вот почему я решил, что этот тест больше всего тестирует ФС. Конечно можно 20Мег за секунду скопировать с одного каталога в другой :-), но это же всё в буферах будет, надо много=много копировать ... 600 Мег например ... У меня пока нет СКАЗИ винтов чтобы они были 100 процентно гарантированно быстрее 100М/бит сети ...

Господа, я не понимаю что вы изобретаете велосипед в тестировании файловых систем?

Отхватываете большой каталог и копируете его в /dev/null под линуксом и в null под Виндой. Вот вам и ЧИСТЫЙ ТЕСТ ФАЙЛОВЫХ систем.

А теперь быстро побежали, проверили закончили гнать пургу.

Антихрист. По твоим высказываниям сразу видно, что ты и есь тот самый юзер-кретин из-за которого админы ставят журналируемые системы. Админ должен то, админ должен это, отрезать яйца... Кастратор мля...

Я пока не видел ни одной конторы, где начлальство выделелило бы деньги на нормальную защиту оборудования ДО НАСТУПЛЕНИЯ очередной неприятности. Кстати, от юзера не требуется ругаться с начальством, бухгалтерией, электриками, сантехниками, госсвязьнадзором, налоговой, ремонтниками, строителями, детьми начальников, энтузиастами, интересующимися пионерами и целой другой кучей мудаков, которые своими вольными или невольными действиями или бездействиями могут причинить вред серверам. Юзеру требуется только понять, что существуют обстоятельства непреодалимой силы, которые независят от админа. Вот такие обстоятельства и лечатся журналированием и ненадо нам никаких сказок про УПСы. Руский человек, особливо дурак всегда придумает как любую систему защиты сломат, особенно после принятия любимой жидкости.

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

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

И как, по мнению онанимуса, журнал защитит от железных сбоев? E.g. хрюкнулась память -> говно в журнале, хрюкнулся контроллер -> говно в журнале, хрюкнулся винт -> вообще кирдык журналу. Так что обломись, онанимный великий гуру, не то ты применение ЖФСам нашёл.

А ты что, так и будешь ждать, пока батарейка сядет, заместо того, чтоб шатдаун корректный изобразить?

Преимущества NTFS перед уродским FAT32 вовсе не только в журнале. И вообще, я NT не ставлю. Никуда. Мне писюки с их недоосами никуда не впились.

2speer:

Насколько я понимаю вся проблема с NTFS объясняется до банальности просто - безумное время уходит на балансировку дерева, впрочем, как и на других системах, основанных на B-trees. Например дома у меня стоит ReiserFS и при разархивировании исходников ядра Linux 2.4.х сперва довольно быстро копирует файлы, затем затыкается на довольно продолжительное время, потом дальше копирует. С ext2 такого не происходит, у нее копирование идет плавнее. Хотя в целом она и медленнее. Но про ntfs давно известно, что это не лучшая система и в большинстве случаев она проигравает FAT32 ( иное сравнение некорректно). Несколько я знаю Linux+ext2 быстрее NT+NTFS, но по многим тестам и Linux+ReiserFS быстрее Linux+ext2, хотя с ней такие притормаживания случаются. Как кто-то давно, заметил ( еще до выхода XFS, ext3) каждая FS - для своих задач. Недостатки есть у всех. Но и достоинства тоже у многих...

Во как хлопца за живое задело! Весь на говно изошел. В точности свой ник оправдывает.

Грусно друг мой Антихрист. Грусно. Я думал ты умнее. Или хотя бы вежливее.

Все ты говоришь правильно, только вот тон твой очень даже не хороший. Ну только не надо говорить типа "Не надо меня учить". Я и не учу. Тебя жизнь научит. Подрастешь и все поймешь. Терпимости наберешся... может быть... Ну а если это не случится, то не беда. В природе должен быть баланс. Кто-то должен быть умным, а кто-то очень тупым...

За сим прощаюсь.

and3008

Для идиотов: файловые системы, что поддерживает LINUX. XFS, EXT2, EXT3, ReiserFS, FAT, FAT32 ядро Linux полностью поддерживает ( в режиме rw), а NTFS - нет ( только ro). Конечно можно сделать тест производительности сдвоенной системы запись с Win2000 на раздел, а потом считывание системой GNU/Linux без учета времени на перезагрузку и с учетом оного ))).

2and3008:

Как у Окуджавы: "... на каждого умного по дураку, все поровну, все справедливо..."

Когда закончатся посты с перекидыванием булыжников в огород соседа? Вот предыдущий оратор высказал пару умных мыслей, но кинул камешек в огород Windows. NTFS ему не нравится. Думаю куча народу считает иначе. Опять порождение флейма.

Если и говорите, что чем-то ФС очень хороша или плоха, то результаты тестов в студию!

А то опять порождение флейма. Пустого и нудного.

Если я говорю не нравится - я не заставляю вас возненавидеть ее. Я не занимаюсь пропагандой или воспитанием духа. Почему когда в обычном разговоре между двумя людьми если один кидает слово "не люблю" или "нравится" второй, обычно, лишь высказывает свое мнение в той же форме, но злостного убеждательства не происходит. Итак, чем не нравится: медленно работает, долго ищет файлы в Фаре по F7, и дефрагментация не помогает. Если кому-то она нравится до безумия - я его пойму - мне так нравится ReiserFS. Тем, что описана ее структура, народ делает какие-то тесты явно способствующие улучшению, быстро ищет в mc по Alt-Shift-/.

Просьба не убеждать меня ни в чем. Сам знаю, что вышеприведенное - не аргументация.

ВСЕ!

1) Эээ... Типа того... А где пионЭрам можно прочесть про то, что такое эта самая жФс есть и в чем разница между ней и нежфс ???? Лучше бы на великом и могучем, который по совместительству еще и родной...

2) И еще.. Может оно немного не в тему - но зато с тестами !!!! :-)))
К тому же если не разобраться с этим вопросом, то все дискусси на тему скорости работы с фс будут бессмысленны :-)))))
Итак:
Тестовая система - Abit KT7A (VIA KT133A) + 750-ый Дурик на 256 метрах.
hda - 40 гектарный фуджитцу на UDMA(100)
hdd - CDROM Samsung scr-3232 DMA (Дерьмо редкостное, как вроде и все, что для компов от самcуньга...)
hdc - Квантум Огненное Яйцо на 2.5 гектар UDMA (33) (С матерью тока один шлейф в поставке был :-((( )

"Как мы тестировали..." :-)))) Брался файлик с видеофильмом метров 600 с лихом и копировался с каждого из трех иде-устройств на остальные устройства (кроме сиди :-))) ) в те же самые места на диске (в обоих случаях для чистоты бралась FAT32). Под Win98SE с Все_В_Одном_Флаконе от VIA 14.35 и под LInux 2.4.17 с одного из мирроров от kernel.org без патчей от Кокса или кого-либо еще, с поддержкой одиозного 686B и автоматом воткнувшемся при пересборке "workaround"'ом к нему же. Бивис под мать - WZ. Под линухом копировалось как 'time cp ...' так и под MC. Разброс значений при замерах +_ 0.5 сек.

Win98 Linux 2.4.17
CD -> hda 3:06 3:20
CD -> hdc 3:09 4:30
hda -> hdc 0:59 3:56
hdc -> hda 0:55 3:52


В утешение линуксоидам-фанатикам могу только сказать, что винды с первого раза не поняли, что CD на DMA, и качали тот же файл 17 минут :-))))) Ну и хотелось бы услышать что-нибудь вразумительное по этому поводу... Насколько я понимаю - ни /bin/cp, ни MC не умеют считывать и записывать синхронно - т.е. производить запись, одновременно считывая данные. Но по логике вещей они и не должны этого уметь - это забота ядра. У меня только одна гипотеза - workaround к 686B. В общем ЗДРАВЫЕ и ОСМЫСЛЕННЫЕ, ну и желательно ВЕЖЛИВЫЕ комментарии приветствуются. Остальные лучше всего сразу в /dev/null :-)))))

ЗЫ. Для танкистов - под линухом я одновременно Вольфенштейна не гонял !!! :-)))))

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

Ну кто-нибудь сможет провести тест, который исключит влияние различных ОС на результат тестирования? Чтоб тест выглядел как истинное тестирование ФС. Думаю такое в принципе не возможно...

И еще. Производилась ли под Линухом оптимизация прогой hdparm? Windows ведь небось врубила режим DMA, а Линух врубил?

Опять вопросы. Опять тест выглядит однобоко. Опять повод для нападок.

И еще сомнения меня берут, что 600 мег с диска/на диск перегналось менее чем за минуту. Может мне винты такие медленные попадались...

and3008

2 and3008

<И еще сомнения меня берут, что 600 мег с диска/на диск перегналось менее чем за минуту. Может мне винты такие медленные попадались... >

И совершенно напрасно. У меня под w2k и winxp c одного _винта_ на другой _винт_ фильмы (620-690 Мб) копируются за примерно такое-же время. Если оба UDMA100.

2 Antichrist

Зачем нужны журналируемые системы на серверах :) ??

Мал ты ещё похоже :)

У нас пару месяцев назад, в одном очень известном банке
(не в России) был случай:

Вышла из строя система охлажения в серверной.
Несколько серверов померло :( Правда там солярки в
основном стояли.

Деньги на оборудование здесь не жалеют,
НО случаи разные бывают, мало ли что может сдохнуть...

Потерять данные, пусть даже и лог файлы не очень-то приятно

"Ну опять же вы тестировали не столько ФС, сколько производительность драйверов дисковой подсистемы и ядра."
Именно. О чем я и сразу и сказал. :-))) Сначала нужно с этим разобраться, а уже потом со всякими фс... :-))))

"Производилась ли под Линухом оптимизация прогой hdparm? " Не производилась, потому как производить было нечего - ДМА сразу врубался при загрузке и параметры для каждого иде устройства были одинаковы в обоих ОС. Я же писал, что ядро было пересобрано, а не из дистра. Так что странный какой-то вопрос... :-)))))

"Опять тест выглядит однобоко" Простите, не понял ???? Чего же "однобокого" в этом тесте ???? Или быть может "однобоки" его результаты ??? :-))))) Так это уж не я, это - тест... Линух мне друг, но истина дороже :-))))) А нападки - если по делу, то всегда пожалуйста. Готов выслушать любую конструктивную критику.


"Ну кто-нибудь сможет провести тест, который исключит влияние различных ОС на результат тестирования?" Простите меня за некоторую резкость - но это полный бред. ФС не существует ВНЕ ОС. Поэтому "тестирование ФС" вне операционных систем - это то же самое, что тестировать разные виды памяти не устанавливая их в компьютеры :-)))) Корректно действительно можно тестировать только работу с разными ФС под одной и той же ОС, а все остальное - от лукавого :-)))

Повторяю ещё раз, для самых нервных: при сбое оборудования ЖФС не спасёт, более того, с ЖФС теоретически проблем может быть гораздо больше, чем с традиционными FS - она ведь может откатить БИТЫЙ журнал, и поехать жить дальше, с битой уже FS, а вот UFS, к примеру, имеет все шансы быть восстановленной по fsck. Так что - не фиг гнать про ЖФС на сервере. Смешно это всё.

LamerOk - FAT32 не оптимизировалась писателями ядра линуха, посему она может быть сколь угодно непроизводительна *под линухом*. Если не трудно, скорпируй файлы на ext2 (расположенных в том же месте, где была fat32). Я как бы даже счастлив от результатов теста - значит ядрописатели линуха не тратили зазря свое время на оптимизацию поддержки FAT32, а занимались более полезными вещами.

а что hdparm говорит про блины под лиухом?

2LamerOk
пожалуйста, для отражения действительно ситуации повторите свой тест в зеркальном отражение. возьмите тот же комп и теже файлы и скопируйте тот же файл и под линуксом и под win98 только с/на ext2
Тогда, возможно, вы увидите реальную разницу в производительности.

hdparm говорит следующее:
/dev/hda:
Timing buffered disk reads: 64 MB in 2.21 seconds = 28.96 MB/sec
/dev/hdc:
Timing buffered disk reads: 64 MB in 5.82 seconds = 11.00 MB/sec
/dev/hdd:
Timing buffered disk reads: 64 MB in 29.08 seconds = 2.20 MB/sec

2 hvv и anonymous (*) (2002-01-30 04:05:26.0) - как ни странно, но дело оказалось именно в испльзуемой ФС. Странно - потому что ФАТ - до предела простая файловая система и оптимизровать там вроде как нечего.. Ну разве что вечные циклы повыкидовать :-)))) Так как раздел с фатом на /dev/hda хранит кое-какие данные, под ext2 я его не переразбивал и испльзовал другую партицию на том же диске (находящуюся в самом начале диска, так что производительность должна только возрасти, но ОЧЕНЬ не существенно). Ну и создал на /dev/hdc ext2 раздел. Прогонять этот тест на ext2fs под Win98 я не стал, т.к. во-первых меня интересовала только скорость работы Линуха, а во-вторых в ломы искать поддержку этой фс для виндов и кряк к ней :-))) Кроме того, я проверил и результаты копирования с фат на ext2 и обратно. В качестве фат на hda использовался то же самое место того же раздела, так что можно сравнивать и с результатами предыдущего теста.

Вот результаты тестов:

CD -> hda(ext2) 3:09
CD -> hdc(ext2) 3:47
hda(ext2) -> hdc(ext2) 0:49
hdc(ext2) -> hda(ext2) 0:55
hda(vfat) -> hdc(ext2) 0:50
hdc(ext2) -> hda(vfat) 1:03
hda(ext2) -> hdc(vfat) 1:48
hdc(vfat) -> hda(ext2) 2:15

Все замеры делались time, я проверил ( :-))))) ) - не врет. Некоторые тесты повторялись и разброс значений был в несколько секунд.

Выводы: Ну про то, что Линух работает с диском ничуть не хуже Win98 говорить не буду - побьют :-))) Интересно только то, что фат тормозит работу, при чем в роли источника он выступает или назначения - видимо роли не играет. Ну а если в обоих ипостасях... :-((( Завтра попробую прогнать тесты на тормозиловость фат по нескольку раз - надо же все таки прояснить вопрос.. :-)))))

ЗЫ Глюк с 17 минутным копированием с компакта на этот раз уже на ext2 повторился и под Линухом :-))) Ну и драйв мне достался... Первый экземпляр этой модели я вообще махнул по гаранти... на нынешний... :-))))

2Lamer: результаты у тебя вполне нормальные. Так и должно быть.
Только смысла в этих результатах очень мало. FAT32 в линуксе нужна только
для разовых операций - перелить из/в винду, и оптимизацией ее никто не занимался.
Постоянно с ней никто не работает. Более того, я даже легко поверю, что драйвер
fat32 в линуксе кривой. Но опять же - главная цель была корректно читать и
писать на виндовый раздел, чтоб винда после этого колом не вставала и признавала эти данные за свои.
Да, в винде fat32 относительно быстрая. По моим замерам где-то на 5-10% быстрее чем ext3 при
одиночном копировании файлов и при условии малой дефрагментации. А при высоком
уровне дефрагментации fat32 они уже сравняются. Короче, это вполне естественно,
что более простая ФС может теоретически обгонять на отдельных операциях более продвинутую ФС.

2Antichrist (*) (2002-01-29 18:58:10.0):
> Так что - не фиг гнать про ЖФС на сервере. Смешно это всё.
Слушай, умник, ты, извиняюсь, как всегда, уперся и несешь ахинею.
Как ты ухитряешься еще при этом такую умную рожу корчить!

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

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

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

hda(ext2) -> hdc(vfat) 1:26 2:02 2:19 2:35 1:52
hdc(vfat) -> hda(ext2) 1:29
hda(vfat) -> hdc(ext2) 0:50
hdc(ext2) -> hda(vfat) 1:02

В общем, с фатом линух не очень дружит.. :-(((((

"FAT32 в линуксе нужна только для разовых операций... Постоянно с ней никто не работает." Ну вот мне то как раз нужна довольно регулярно - по 20 гигов копировать. И именно на фат32... И никаких полностью готовых средств для работы с фат-разделами на винте... Ну фдиск то - понятно, но вот то, что и parted облажался - совсем фигово... А то я было губу раскатал сделать себе загрузочный компакт со всякой системной фигней под линухом... Ээээх... :-)))))

> Ну вот мне то как раз нужна довольно регулярно - по 20 гигов копировать. И именно на фат32...

Ну дык эта, рекомендация тут одна ;) Дебаггер с профайлером в зубы и вперед.
Правда не для ламеров это... Линукс хреново работает с фат32? Так возьми
купи за $$$ драйвер ext2 для винды. Что, жаба уже задушила? Так возьми вместо
линукса freebsd или еще что-нить... Что и у них скорость не та??? Ну так мамо, лежите и не 3.1415926-здите!

"Дебаггер с профайлером в зубы и вперед." Ну видимо так и придется сделать.. Разве что без дебаггера :-)))) Только сначал свой dirty-hack для клавы доведу до ума... :-)))))) Ну а потом буду 3.1415926-здить :-))))))))))

Учите МаТаН товарисч....

Теорию надёжности..... Када нана 0.99 лучше 2% производительности потерять чем Журналирование отрублю... А сдохших UPSов ZOD на своей жизни 3 штуки видел..... И один раз дохую ФС с базой на 10Гигабайт каторую бэкапили в /dev/null - тоже думали чта марсиане чаще нападают чем файловая система с УПСОМ грохнется.

Если бы анонимус

имел понятие об алгоритмах заложеных в NTFS и о их реализациях он бы поубавил свой пыл. 1) Это очень сложная и критичная к ошибкам разработка 2) Она не является основной - нуна было делать ext3fs......