Это все хорошо, только у меня xfs слетал раз в неделю, а ext3пашет почти уже пол года без проблем.

Muzhik zabyl proveril proizvoditelnost Oracle na etikh failovykh sistemakh - naprimer, sozdanie bazy dannyh pod Oracle ...

Byl by povod poudivlystsya pochemu na sozdanie 1.5Gb bazy dannyh v Oracle (via dbca) pod Ext3 trebuetsya 2 minuty, a pod ReiserFS - bolee 2 chasov. Machine - Suse Linux Professional 9.0, P4 2.4Ghz, 1Gb, 40Gb + 80Gb UDMA5 HDDs.

S drugoy storony, KDE "letaet" na ReiserFS v otlichie ot Ext3.

Интересно, а еще меньше графики они могли сделать? И потом - ext3 и ext2 последние не во всех тестах. Кроме того, кто проведет тесты на надежность?

именно xfs был виноват? очень надежная фс. расскажите подробней, что было

XFS не очень надежная. Я 3 раза терял разделы после копирования оченьбольшого количества мелких файлов одновременно несколькими процессами. Пусть ext3 медленнее, но сломать раздел на ней куда сложнее.

всем, у кого "слетает" xfs

Расскажите -- ну как это у вас получается? А то у меня руки кривые, никак не выходит ее замучить...

XFS надёжная ? Ну не знаю .. У меня она теряла данные регулярно и за милую душу ; на внезапных перезагрузках улетали конфиги , бинарники : всё что угодно . Одно время у меня стояла "левая" карточка (не важно какая) , что имела особенность вешать машину при определённых условиях . Так вот после перезагрузки во многих файлах , что были открыты в момент зависания , вместо того чему там быть положено -- каша из нулей (в лучшем случае) или куски совсем других файлов (в худшем). Таким образом улетали конфиги XFree , оконного менеджера (причём чаще всего ), что использовался в тот момент , демонов , что были запущенны : никто не остался обделён . Я честно грешил на кривые руки , читал доку , копался в гугле и пробовал , пробовал , пробовал . Хуюшки . Данные как пропадали так и пропадают . Пришлось отказаться от использования этой XFS даже в домашних экспериментальных целях .

А какая журналируема ФС меньше всего процессор "жрет"?
Поставил reiserFS на слабую тачку. Теперь проц проседает.

У меня вот тоже не далее как сегодня (2.4.21) приключилась бяка с разделом на XFS. Что характерно, ничего такого вроде и не делал, это с самого начала, уже года два, глюки при пропадании питания, причём, что характерно, уже на третьей машине. Вот.

А картинки в статье уродские (jpeg на таких картинках - это тихий ужас, ничего не видно)... Убивать таких тестеров надо, которые не могут результаты тестирования преподнести нормально.

:) жаль UFS2 нету ;)

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

я умудрился угробить райзер всего один раз, но это виноваты голова и руки.
единственное, что меня раздражжает с райзером - иногда (раз в несколько месяцев) появляются косяки на партиции (вроде бы без видимых причин). Они конечно лечатся reiserfsck --fix-fixable но это всёравно не дело. :-\
ядра пробовал разные. от 2.4.20 до 2.6.3 (конечно не все, но из этого диапазона.)

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

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

а если учитывать какая из всех этих фс самая фичастая то выбор очевиден - xfs лучшая фс

>А картинки в статье уродские (jpeg на таких картинках - это тихий ужас, ничего не видно)...

Читать умеешь? If the images are hard to read on your screen, here's a tarball containing larger versions of them. Короче тебе сюда: http://linuxgazette.net/102/misc/piszcz/lg-102-piszcz-images.tar.gz

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

Если кого-то и убивать, то только тех, кто кричит не разобравшись.

>А картинки в статье уродские (jpeg на таких картинках - это тихий ужас, ничего не видно)... Убивать таких тестеров надо, которые не могут результаты тестирования преподнести нормально.

If the images are hard to read on your screen, here's a tarball containing larger versions of them.

"Here" - это http://linuxgazette.net/102/misc/piszcz/lg-102-piszcz-images.tar.gz. Хотя все равно не очень разумно..

Более того, и там картинки весьма гаденькие.

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

Оригинал с нормальными картинками здесь:
http://209.81.41.149/~jpiszcz/index.html

2anonymous (*) (11.05.2004 11:23:47)

>Byl by povod poudivlystsya pochemu na sozdanie 1.5Gb bazy dannyh
> v Oracle (via dbca) pod Ext3 trebuetsya 2 minuty, a pod ReiserFS
> - bolee 2 chasov. 
А на raw девайсе ?
Оракел же вроде это поддерживает даже в Linux варианте ?

какие-то странные результаты...

вообще почему никто не тестирует после того как на раздел было записано до половины объема файлами разного размера, часть из которых удалена, потом снова закопированы другие, и так раз 10, а вот после этого и тестировать. ext2/3 и jfs в таком случае будут жутко сосать...

а что касается надежности xfs, у меня однажды на домашней машине при сбое питания похерилась папочка ~/.mozilla с всеми букмарками, было очень обидно. С тех пор уже год работает и все в порядке. А на паре серверов xfs тоже стоит около года и все ок, правда там питание не падает и аптаймы почти по полгода =)

Кто б сомневался: ФС с журналированием данных и с линейным обходом таблиц inodes против ФС без журналирования данных и с деревянным обходом таблиц inodes. Козе понятно, что в таких условиях ext3 в заднице. А надёжность? А если с раздела данные только читаются? А если ядро 2.6 и ext3 с bi-trees?

А зачем нужна журналируемость?

Это типа понты такие.

ocen ponravilos eto, rekomenduju: http://otn.oracle.com/oramag/webcolumns/2002/techarticles/scalzo_linux02.html

RTFM.

Журналирование не гарантирует сохранность данных. Оно гарантирует _непротиворечивость_ ФС.

> Одно время у меня стояла "левая" карточка (не важно какая) , что имела особенность вешать машину при определённых условиях .

Берем нормальное железо. А на убогом пользуем убогую ФС -- ext3.

> Так вот после перезагрузки во многих файлах , что были открыты в момент зависания , вместо того чему там быть положено -- каша из нулей (в лучшем случае)

Нули там бывают, если одновременно писать в кучу файлов (на одной ФС), которые рядом лежат ( в B-tree ), и в этот момент...

> или куски совсем других файлов (в худшем).

Так только ReiserFS могет ( с включенным tail-merging ).

> Таким образом улетали конфиги XFree , оконного менеджера (причём чаще всего ), что использовался в тот момент , демонов , что были запущенны : никто не остался обделён .

Интересно, а каким образом получалось так, что при всем этом шла запись в корневую ФС? Кусков из других файлов там не может быть ( нули бывают ).

А че тесты от оракел - это типа универсальное мерило крутости фс?

А если взять фтп сервер с 10000 одновременными сессиями?

>Берем нормальное железо. А на убогом пользуем убогую ФС -- ext3.

Своё железо -- поводов жаловаться не даёт : всё в лучшем виде . Но иногда нужно работать с чужим , тогда пляски с бубном и начинаются .

>Нули там бывают, если одновременно писать в кучу файлов (на одной ФС), которые рядом лежат ( в B-tree ), и в этот момент...

Угу . Звучит логично . Бороться с этим как-то можно ?

>Так только ReiserFS могет ( с включенным tail-merging ).

Значит я перепутал и то был рейзер . Очень может быть .

2Sun-ch (*) (11.05.2004 15:30:11)
>А если взять фтп сервер с 10000 одновременными сессиями?
Угу, и все заливают, заливают ...
Sun-ch, хватит нести пургу, зима уже прошла.

2Cannabinolus (*) (11.05.2004 15:32:00)

>XFS надёжная ? Ну не знаю .. У меня она теряла данные регулярно и за милую душу ...
>Cannabinolus (*) (11.05.2004 12:53:21)

>Значит я перепутал и то был рейзер . Очень может быть .
>Cannabinolus (*) (11.05.2004 15:32:00)

Поздравляю Вас, господин, соврамши :-) Так все-таки, что это было? Может minix? :-)

Запарили нах пионеры со своими ссылками на оракел, типа ляпикс крут не подецки и тресь ссылку на оракел :)

2Sun-ch (*) (11.05.2004 15:56:51)
>Запарили нах пионеры со своими ссылками на оракел, типа ляпикс крут не подецки и тресь ссылку на оракел :)
Для общего развития, под GPL есть еще одна FS - Oracle Cluster File System, жаль только ее в тестируемый список не включили.
P.S. Это насчет Oracle.

А к чему Вы это привели?

Кроме, как пускалка для оракела, ляпикс используется еще много где,

так что данные тесты тут непоказательны.

Правильно, потому что картина была бы довольно печальная ;)

2Sun-ch (*) (11.05.2004 16:08:54)
>А к чему Вы это привели?
Я же написал, для общего развития :-)
>Кроме, как пускалка для оракела, ляпикс используется еще много где,
>так что данные тесты тут непоказательны.
Да неужели? :-) И что, на проксю под кеш или на ftp-архив (ro) бум ставить супернадежную, но медленную FS? А на рабочую станцию, в любом случае работающую с сервером?

А что большой опыт работы с ufs/ufs2?

Откуда такая уверенность?

Главное это надежность, а для производительности покупают нужное железо.

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

Надёжность - возможно, но скорость не самая лучшая. Хотя здесь всё, конечно, зависит от задач.

Если с такой позиции подходить, то возможно UFS будет достойным выбором.

>>Если так дешевы, то переведите, пожалуйста на мой счет $NNN

>Чай не благотворительное общество тута. А про дешевизну процессоров и >памяти - это к тому, что вы - жабщики любите так говорить. Причем в >основном не к месту. "А давно ли вы заглядывали в прайс? Память нынче >копейки стоит. Чай не 2002 год на дворе."
Я не просил совета, куда мне девать деньги!
Когда попрошу, тогда - милости просим.
Это ваша мысль была про дешивизну.
Отвечать за свои слова и дуратские советы не каждый может.

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

>Согласен, но заметьте не опять таки не все. Х*******п******ю*тать! 
Других не встречал. И вы подтверждение правила.

2Sun-ch (*) (11.05.2004 16:25:21)
>Главное это надежность, а для производительности покупают нужное железо.
Так и запишем, разработчики RAID-массивов и UPS-ов даром едят свой хлеб, бэкапы не нужны, главное - железо помощнее взять.
Кстати, по каким критериям будем оценивать надежность? Про аттрибут sync забывать не будем, ок?

http://oregonstate.edu/~kveton/fs/ - а вот тоже посмотрите, интересно

Тесты на Promise ATA/100 для людей использующих оракел?

Не смешите мои тапочки, это интересно только для дом. пользователей.

2Sun-ch (*) (11.05.2004 16:43:34)
>Тесты на Promise ATA/100 для людей использующих оракел?
>Не смешите мои тапочки, это интересно только для дом. пользователей.
Это где-ж Вы такое усмотрели? Интересно, с переходом на SCSI RAID скорость ... упадет ? :-)
Саныч, ку сколько можно? :-)

Очень интересно, ext2 практически во всех тестах оказалась быстрее

всех на Bonnie++

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

2Sun-ch (*) (11.05.2004 17:03:28)
>Только не надо забывать, что у них были 15к шпиндели и крутой скази рейд контроллер.
Ну и хто там про крутое железо говорил? :-)

а разве ext2 не будет по любому быстрее ведь она ж без журнала

CONTROLLER: Promise ATA/100 TX - BIOS 14 - IN PCI SLOT #1
DRIVES USED: 1] Western Digital 250GB ATA/100 8MB CACHE 7200RPM
2] Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM
DRIVE TESTED: The Western Digital 250GB.

Новость то читали?

2anonymous (*) (11.05.2004 17:07:47)
>а разве ext2 не будет по любому быстрее ведь она ж без журнала
На большом числе маленьких файлов или на ОЧЕНЬ больших файлах (>2G) и интенсивной работе с ними нет.

А может его (Oracle) тонко оттюнить надо было? Видел чудеса тюнинга на Oracle, когда не меняя запрос, только настройкой, повышали производительность на порядки :) Может там просто какое-то неудачное совпадение для ReiserFS было, какой-нибудь худший случай :)

2Sun-ch (*) (11.05.2004 17:08:09)
>CONTROLLER: Promise ATA/100 TX - BIOS 14 - IN PCI SLOT #1
>Новость то читали?
Ну и ... меняем энтот промайс на SCSI-RAID LSI, Adaptec или CompaqArray (перечислил только те, с которыми работал) ... получаем еще больший прирост производительности, особенно, если индексы на RAID0 (в крайнем случае пересоздать можно).