Коментарий Линуса по поводу RedHat.

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

Наш горячий финско-шведский лидер, вообще-то, известен как человек консервативный (что есть хорошо). И он абсолютно прав, что совсем не надо переводить mainstream на 2.96 только из-за того, что кому-то взбрело в голову включить "сырой" компайлер в дистрибутив. (Сиё мы, кстати, обсуждали здесь не так давно)

Но вот наезды на красношляпников безосновательны. Как известно, "redhat!=linux", и ставить ядра с ftp.kernel.org на шляпу противопоказано. Если же ставить "фирменные" ядра -- никаких проблем нет.

автору:
Со всем уважением, "перешол" пишется как перешел :))

А у меня на RH 6.1 только с kernel.org и стоят...

И меня уж сколко лет только они и стоят :)

2Dronov:
У меня в РХ 7.0 как раз "фирменное" ядро 2.2.16-22 ни фига не компилится, а вот 2.2.17 с ftp.kernel.org без проблем собирается и работает.

И у меня, и у меня тоже. :) Я полтора года назад поставил RH6.0 С тех пор многое изменилось... :) Да и от прежнего RH мало что осталось.

Интересно, а как Кокс на это реагирует. Все-таки он в RedHat и второй человек после Линуса.

tam zhe, sobsno, i napisano wbr

Учту :) Я уже просил макскома добавить опцию update.

Никто не отрицает, что с помощью известной матери можно трактор "Беларусь" обработать напильником до баллистической ракеты. :)Просто если от ядра нужен только ide driver, то оно, конечно, проблем и/или сложностей ожидать глупо.

Hint: советую посмотреть на количество патчей, включенных в красношляпное ядро. Вряд ли они эти патчи туда просто так запихнули, от нечего делать. И уж совсем глупо предполагать, что в шапке нет софта, который предполагает наличие этих патчей в ядре.

Примеры софта? У меня хостинг БОЛЬШОЙ под ядром без патчей. Ещё ничего левого не глючило. Глючат только программы, написанные в egcs, когда типы неявно преобразуются.

Вполне может быть, но я за 3-х годичную эксплуатацию RH разных версий на такие проблемы не натыкался. Всегда использую ядро с kernel.org. Вот вчера 2.2.18 патч скачал... На серваке работает туча всяких прог (оригинальных, из RH 6.1) типа Samba, Mars, Bind, Sendmail, Apache, PostgreSQL, mgetty+sendfax и т.д. Особых проблем не замечено.

2 dronov:
Известно следующее ....
После выпуска 7-й шляпы сами изготовители признали что ядро не компилится даже собственное
так что не надо по поводу (linux != redhat)
шляпа ничем особым не отличается от других дистрибутивов...
СуСе гораздо более пропатчен и удалён от стандарного линукса (казалось бы)
но не так давно его признали наиболее близким к стандарту.
А с ядрами с kernel.org я всю жизнь на шляпе работал.

Ааа, ну если еще и под нагрузкой...

Dronov, разглядывая linux-2.2.16-3c90x.patch, linux-2.2.14-PIII.patch, linux-2.2.16-aic7xxx-5.1.*.patch, linux-2.2.16-iobuffix.patch, linux-2.2.16-raid-B2.patch, linux-2.2.16-scsi-reservation.patch, linux-2.2.16-server-tuning.patch и linux-2.2.16-vm-backout.patch (которых, естественно, _нет_ в "стандартном" ядре) выкорвырянные из kernel-2.2.16.src.rpm. A ведь 2.2.16 было основным ядром почти пол-года.

SuSE? Не смешите мои тапочки. Заметьте, это не я перевел разговор на сервера, но в "серверном" контексте упоминание SuSE с его reiser fs без квот и работающей только на x86, с его ide patch, от которого ALI15XX чипсет завешивает все наглухо при использовании DMA, с его способностью создавать нечитаемые core на AMD...

SuSE пркрасная вещь для домашнего применения чайниками (чего только стоит зависимость xmms->gnome!), которые загружают его раз в неделю показать знакомым, что "линукс -- это круто", но для серьезного применения...

Особо интересующиеся могут сходить на dejanews.com и почитать в архивах fido7.ru.linux рассказ Alex Korchmar о поддержке SuSE своих старых версий (про syslogd update).

Я так думаю, что RH это наверное единственная контора *занимающаяся* линуксом, все остальные клепают дистрибутивы только чтоб заработать прямо сейчас. Что же касается проблемы 2.96 я думаю они сделали это правильно, т.к. тем самым вынудили писателей ядра пофиксить compiler-version dependency (это же было идиотсво когда исходный текст зависил от особенностей реализации конкретной версии компилятора) и за одно ускорили разработку gcc3.0.

квоты у ext2 есть и без Сусе и в Сусе они тоже есть! xmms на сервер вы ставить все-равно не будете, поэтому не так и страшен он для вас. Все-таки SuSE достаточно универсальная штука. Кстати, в SuSE входит и стандартное(vanilla) ядро для тех кому оно больше идет. И еще вопрос не в тему -- у вас сервак на ALI? и AMD? то есть ни SCSI ни SMP? Не знаю, стоит (6.4 и 6.3) на серваках и аптаймы по 3 месяца бывают ( свет иногда отключают просто ) Ну просто почему-то работает и все. 7.0 не пробовал -- тянуть много и не охота -- вот может 7.1 или 7.2... А fido7.ru.linux просто не заставите читать. Жуткий объем трафика в день и по 300 мессаг на тему > маны читать не буду английский не знаю но надо чтобы все работало и вот чтобы прямо как нибудь с "пере-под-вы-под-вертом".... тьфу. > О чем там можно почитать?

P.S. который, как всегда, идет впереди. :) Между прочим, исходно разговор шел о том, что тот, кто использует не "одобренные" ядра (читай -- не от своего vendor'а) ищет приключений на свою задницу и не стоить сильно удивляться, если он их находит. Мне же стали доказывать, что "обточить напильником" можно что угодно.

А теперь идем по пунктам:

Это где ж я говорил, что нет квот на ext2fs? На reiser fs их нет (вернее, не было, вроде, сейчас появилось). Только вот сузя-то норовит все reiser предложить. Да и reiser-та x86 and linux only (ext2 я, на худой конец, даже из-под вынь прочитаю).

dependency xmms->gnome была приведена как пример чайнико-ориентированности. (и даже выделена в отдельный параграф!) Если не нравиться такой пример, пожалуйста, другой: 99% src.rpm "не знают" о существовании RPM_BUILD_ROOT.

И много пользы от той ваниллы, когда понасоздаете себе разделов c reiser?

На сервере у меня с недавнего времени SPARC, чему я очень рад (не надо больше ломать голову, что из патчей мне нужно, что можно выкинуть, а что надо утащить где-то еще). А вот насчет scsi и smp советую посмотреть объем патчей на эту тему в той же сузе (или шапке). Хотя, там же народ в сузе и шапке такие дурни, что пихают в ядро что ни лень, лишь бы объем был поболее... (особенно linux-2.2.16-server-tuning.patch нафиг не нужен)

Полный оффтопик: есть такие вещи как filter, scoreing и многое другое... И предлагалось не подписаться на эху, а пойти в архив и поискать конкретное сообщение.

> Вот вчера 2.2.18 патч скачал...
Э... поторопился.
2.2.15-18 в чистом виде (без патчей) - нерабочие ядра (спасибо товарищу Коксу,
в редхете он почему-то делает их рабочими).
До 2.2.14 - проблемы с безопасностью. Что остается?

Dronov,
Ты бы разобрался все таки в патчах от RH а то просто как маленький.
Все RHвские патчи либо для поддержки железа либо баг фиксы которые просто в ядро еще не утвердили. Потому никакой зависимости от "сборшика"
ядра в RH нет.
К примеру:
Ядро на RH 6.2 сервере
Linux nautilus.digisle.com 2.2.18pre15-reiserfs-crypto-pIII-tima #1 Wed Oct 4 18:34:53 PDT 2000 i686 unknown
41 день аптайма.

Квоты на серверах нужны как зайцу свисток, а вот журнальные fs - очень даже.Кстати RH не включает reiserfs отчасти из-за некоторой несовместимости reiser и bigmem патчей, входящих в RH уже бог знает с каких пор.

Solaris/SPARC хорошо, a Linux интереснее.
На мне висит досмотр за 75+ Solars/SPARCов и дюженой Linux так мне с Linux душевнее. Solaris нуден застойной политикой Sun против которой к сожаленю лекарств нет - propertary software. Проще Linux сделать лучше чем Solaris чем убеждать Sun вернуть C компилятор в систему.

> На сервере у меня с недавнего времени SPARC, чему я очень рад

Месье тонкий извращенец? Линукс на спарке, это даже хуже, чем солярка на x86
Только посмеятся можно с такого гибрида и снести нафиг.

Havoc,
Пробовал Linux на SPARC?
Из моего опыта для многих проектов подходит больше чем Solaris.
Пробовал Solaris на x86 (На системах класса Compaq ProLiant)?
Не Solaris на SPARC конечно, но также найдется целый ряд проектов где Solaris/x86 будет хорошим решением.
Рекомендую меньше смеятся :)

> Квоты на серверах нужны как зайцу свисток

Tima, это слишком смелое высказывание. Если свистишь, то называй сферу
применения таких серверов. Надеюсь, это не относится к серверам с сотнями
виртуальных хостов, управляемых юзерами.

Tima, Вы меня удивляете. Ладно, квоты вопрос спорный (кстати, не совсем -- очень полезно процессам ограничивать аппетиты на /tmp). Но зачем на _сервере_ журналируемая файловая система? Чтобы тормозило? Журналируемая fs, все же, тормознее by design. Да и, самое главное, журналируемая fs не дает гарантии сохранности _данных_. Я предпочитаю потерять файл целиком, нежели получить внутри него черте-что. На _сервере_ нужно raw io, на котором будет лежать DB storage (который внутри себя таки ведет журнал, но для _данных_). Лучше не иметь иллюзий. А для надежности _файловой_ системы сервера надо "прикрывать" UPS'ами с запасом в N часов (а уж за эти N часов дежурный админ к серверу доберется, ибо на пейджер получит сообщение сразу, как питание пропадет).

А про патчи от красношляпников.. Скажу без лишней показухи -- у меня уже не хватает квалификации (и времени) разобраться, что там нужно, а что -- нет (кроме вещей, явно для специфичного железа). А понимаю, что мне не нужно linux-2.2.16-eepro.patch. А вот почему там есть linux-2.2.16-raw-fixup.patch и linux-2.2.16-raw-fixup2.patch? Нужен ли мне второй, если мне явно не нужен первый? А если мне нужна поддержка 4Gb? А что такое linux-2.2.16-slab.patch или linux-2.2.16-kvmfix.patch?

Поэтому я для себя решил принять как аксиому, что Alan Cox разбирается в linux kernel лучше, чем я.

Имел удовольствие видеть
>Из моего опыта для многих проектов подходит больше чем Solaris.
Обоснуй. Разве что на слабеньком однопроцессорном тазике он может что-то показать.
Ты просто хочешь сказать, что линукс может круто работать на чем угодно.
Круто он может работать на x86 и неплохо на альфе, не более.
Это называется лишь бы куда-то всунуть.

Ну я пробовал. На старых-старых тазиках это еще осмысленно, но начиная с ультр смысл sparc linux теряется.

По поводу raw io - блах-блах. То-то ораклс саном говорят "Нафиг-нафиг raw io, используйте fs без кеширования-и-всяческих-других-прибамбасов. И дежурный админ не должен сидеть за N часов от сервера, а за N метров от него же. Ибо нефиг - в дороге может вякое случится.

Гкхммм, ну что Вы, право... Либо смайлики ставьте, либо глупостей избегайте. В любом сравнительно серьезном применении всегда _есть_ дежурный админ, функция которого и заключается в том, чтобы "_быть_ в N часов пути от сервера". А вдруг потоп? Вот его функция и есть за N часов добраться до сервера и вытащить ленточку с последним backup. Другое дело, обычно эта функция возлагается на security -- благо мозгов там в избытке не надо, а security один фиг on site 24x7 присутствуют, так что у них N<1 :). Вот тут народ есть, кто ISP. Я если у Вас там там пьяный дядя Вася силовой кабель топором перерубит? Это там, где RH делают это невозможно, а у нас, как известно, возможно все...

А raw io, дык кто ж виноват, что у нас его нету до сих пор. Мы и виноваты. Я даже сказать могу почему: не нужно было. Как oracle у нас появился, так и raw io начали делать. Авось, оно скоро и заработает. Да и вопрос был не о том. Вот, ладно, мне не нужен raw io, но нужно bigmem. Какой raw-blah-blah я могу выкинуть (все, только один /_какой_?/ или ни одного)? X3? Вот и я о том же...

По поводу SuSE и RPM - у меня SRPM от Solaris лучше собираются :))))) По поводу Sparc 32-bit - всё на него пробовал, Solaris - лучше всего. Если уметь настраивать (Ну, если не чайник в юниксе) - грузится быстрее Linux / *BSD, имеет огромную поддержку юзеров, отличное ядро отлично совместимое с POSIX. Всё GNU отлично портируется. В чём проблемы? Единственный случай - когда Cytrix ставил один чел... Ну, это его проблемы были, он просто не знал про VNC.

Dronov,
Веришь - неверишь мне за последние 5 лет не приходилось настраивать квоты ни разу. Почему? Отчасти потому что не работал в мелком хостинге - 100Мб - 5$/m и т.п. Хостинговые клиенты хотят либо co-lo либо dedicated. Корпоротивные intanet тоже от квот плюются, считается полным бредом работников ограничивать. /tmp на Linux естественно делается простым партишином и пускается cron для его очиски а на Солярке tmpfs со всем справится замечательно.
Reiserfs дело не тормозит а наоборот ускоряет I/O в среднем 5-10 раз. SQL серверам конечно не поможет а вот apache,ftp,cvs и всяческим файловым шарам - очень даже.
Я полностью согласен что Cox знает как собирать ядро и это замечательно что он участвует в сборке ядра RH. Cox кроме того выпускает сейчас 2.2 ядра и 2.2pre серию в которую он уже включил большинство мелких патчей которые околачивались в 2.2.16 ядре RH. Принципиальные патчи которые затрагивают "философию" остались. Bigmem и зависимая от неё rawio.
linux-2.2.16-raw-fixup.patch и linux-2.2.16-raw-fixup2.patch это как раз части rawio патча (если я правильно помню).
linux-2.2.16-kvmfix.patch - патчь для KVM ящика. Мне для KVM понадобилась.
linux-2.2.16-slab.patch - врядли

Havoc,
Обоснование чего? Что apache+mod_perl/php/mysql работает на linux на Сановской Netra T1 105 более чем замечательно (в несколько раз эфективнее чем Solaris)?
Или что тот же apache с jserv работает на 2х процессорном Compaq ProLiant DL320/DL360/DL380 лучше чем что либо другое?
Рекомендую ознакомится с http://pigbirty.fiver.net чтобы пропали домыслы о Solaris на x86.

Ice
На стареньких тазиках самое осмысленное это SunOS - замечательная система.

Аааа, Tima, так бы и сказали, что для Вас сервер -- это apache, ftp, cvs. Кстати, как в двух последних случаях можно обойтись без квот -- хоть убей, не пойму (а уж если там smb fileshare или nfs...). Если только оно anonymous и сторого read-only. А если у Вас apache отдает "статику", то Вам действительно много чего не нужно. Только, обычно web server -- просто "интерфейс" к app server, коротый "плюется" данными из DB storage (да вот, хотя бы, linux.org.ru). Вот, например, как чистить /tmp по крону, если "сойдет у ума" app server и начнет создавать временные файлы со скоростью N,000 штук с секунду (естественно, не пустых)?

Последний раз про патчи. Советую раскопать src.rpm и _посмотреть_ на эти патчи. А специально выбрал для примера "простые" вещи -- там всего 2 строчки. Только для меня абсолютно на ясно, почему это два _отдельных_ патча, какое отношение имеет второй к raw io и зачем он вообще нужен даже с raw io. Поэтому я не могу с уверенностью сказать -- нужно оно мне или нет. Приходится доверять Cox'у.

Dronov,
Чего тут понимать?
Может Вы и мыло корпоративным пользователям ограничивать будешь по 2Mb?
Так я Вам расскажу результат - уволят через два дня после того как один пользователь захочет послать другому очень важную презентацию на 10Мб. То же самое с другими приложениями.
Когда "application server" сходит с ума - действительно плохо, особенно когда application server использует tmp для временны файлов а также когда /tmp не является отдельным разделом. А "специалистов" которые не умеют с /tmp и вообще организацией разделов обращатся - в шею гнать.
Сервер для меня то за что платит заказчик.
Сейчас платят как раз за cache/apache/netscape-ss/logs/ftp/samba/mysql/oracle/sybase и все иже с ними.
Не желаете верить - не верьте, мне то что. Kвоты мне приходилось делать последний раз в году 95 в универе где акаунты студентом в виде одолжения делали.
Вы меня пальцем в src.rpm не тыкайте как будто я его ни разу не видел. Если Вам не ясно почему в rpm 2 rawio патча вместо одного - действительно лучше положится на профессионализм дяди Coxа.

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

ifconfig,
Во первых я словами попусту не кидаюсь, а во вторых я за reiserfs не агитирую. Все зависит от задачи. Reiserfs хорошо себя проявляет в задачах а-ля файловый сервер на больших/средних разделах. По моим тестем (которые меня убедили в оправданности использования reiserfs), поиск на reiserfs в 10 раз бысрее чем на ext2, создание/удаление быстрее в 5 раз. Вот и делайте выводы.

Tima_ Ну откуда ты такие цыфры берешь? наверное на глазок меряешь и "получаешь" тот результат который хочешь видеть, это называеться предубеждение. По моим тестам reiserfs быстрее ext2 но не намного (ну совершенно точно не в 10раз на поиске), а вот проблемы с несовместимостью версий и прочий геморой при upgrade дорогого стоят. В подавляющем большенстве применения линукса как сервера (т,е небольшая контора 5-50 компов почта/internet/самба и иногда кое-что еще, да зачастую на 10Мб сетке) cкорость не критична, а вот надежность и безпроблемность ДА!!! Есть русская поговорка "тише едешь , дальше будешь", в применении к админу комерческой организации звучит так: "меньше экспериментов дольше будешь работать и спать спокойно", так что пока reiserfs не включат в ядро как stable, радоваться ее скорости предпочитаю дома, а там и квоты никчему:)))

"'Вопросов больше не имею' - быстро сказал Остап.". Я ему про app server, а он мне про "важную презентацию на 10Mb". Оно понятно, почему "reiser fs в 10 быстрее": http://www.namesys.com/db_ben.html

Ага, интересные диаграмки. Я вот только до сих пор не пойму, почему на левой
сравнивается ext2fs 4k block, а на правой - 1k block. Ведь судя по заголовкам
диграмм цель была показать разницу, получаемую с приростом количества/мощности
процессоров. На правой картинка получилась более приятной для reiser, но
уменьшение размера блока явно играет против ext2fs. Вот и думай...

Dronov,
Ну а зачем же еще ко всему прочему путать божий дар с яишницей и файл
сервер с сервером баз данных? 
Ну раз просили реальных бенчмарков - пожалуйста.
Bonnie++ на моем скромном домашнем компе P3/500 256MbRAM и вот такой
IDE диск:
/dev/hda:
 Timing buffered disk reads:  64 MB in  3.33 seconds = 19.22 MB/sec

На ReiserFS разделе:

Machine          MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Unknown         200  7201  97 15647  32  5731  11  6614  77 13601   9   nan -2147483648
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 30  3480  97 29128  98  5895  98  3356  98 28722  98  5112  98
Unknown,200,7201,97,15647,32,5731,11,6614,77,13601,9, nan,-2147483648,30,3480,97,29128,98,5895,98,3356,98,28722,98,5112,98

На Ext2 разделе:

Version  1.00       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine          MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Unknown         200  7920  94 23202  11  6710  11  7504  87 13563   7   nan -2147483648
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 30   173  97   577  98  5657  98   177  96   740  98   535  68
Unknown,200,7920,94,23202,11,6710,11,7504,87,13563,7, nan,-2147483648,30,173,97,577,98,5657,98,177,96,740,98,535,68

А теперь для тех кто не понял объясню где именно 5-10 раз.
На ReiserFS создается файлы 3480 раз в секунду в секунду последовательно и 3356 произвольно против Ext2 173 раз последовательно
и 177 произвольно.
Итого производительность выше в 20 раз.
Читаются файлы  29128 против 577 последовательно и 28722 против 740.
Итого 50-40 раз.
Удаляются файлы 5895 против 5657 и 5112 против 535. Итого - равно при
последовательном в 10 раз лучше при произвольном.

Если также обратить внимание на работу с большими файлами то ReiserFS
ведет себя так же как и Ext2 лишь последовательный блочный io подкачивает.

А теперь bonnie++ на 2х процессорном серваке P3/500 с IBM SCSI RAID0 и Ext2.
Version  1.00       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine          MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Unknown         200  7444  99 114269  99 39825  98  7912  99 124721  99   nan -2147483648
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 30   162  99   537  99  5320  99   163  99   685  99   511  76
Unknown,200,7444,99,114269,99,39825,98,7912,99,124721,99, nan,-2147483648,30,162,99,537,99,5320,99,163,99,685,99,511,76

Файловые операции остались все на том же уровне a работа с большими файлами улучшилась на порядок.

Надеюсь я достаточно ясно аргументировал превосходство ReiserFS на Ext2 для файл серверов.

2Tima_: у меня вопрос возник глядя на Ваши данные, как получается, что на ReiserFS (RFS) блочные опперации чтения от 1.10 до 1.5 раза медленнее чем на ext2 (7920/7201 и 23202/15647) и практически одинаковые по записи. Как в таком случае получается такой выигрыш у RFS при чтении?
PS это не наезд, а просто попытка понять результаты.

Org,
Выигрывает reiserfs внушительно на операциях с большим колличеством файлов сравнительно небольшого размера проигрывая при этом на операциях с одним "толстым" файлом. В Ext2 значительную часть времени занимает "подкрутка" нужного файла. Абосолютно очевидно что журнальные fs должны иметь приемущество в операциях над файлами это собственно одна из центральных идей их архитектуры.

(Ошалело крутя головой) Какой файлсервер, при чем здесь файл сервер? Я вроде всю ночь про app server говорю. А начали мы вообще с kernel patches. :)) Ааа, это про benchmark... Да Боже ж мой. "Вы хочете вискас? Их есть у меня." (C) :)) На том сайтике много разных тестов. Даже плюсатая бонни есть. Но мы вернемся к базам данных:

http://www.namesys.com/sql_ben.html

И что-то я не понял, чем bonnie от bonnie++ отличается? У меня с bonnie на PIII 555Mhz IDE циферки были совсем другие... Может, у меня файл меньше был... Да и на SCSI тоже получше было было...

Аааа, http://www.coker.com.au/bonnie++/diff.html "Then I started playing with the Reiser file system and found that Bonnie didn't run any faster on ReiserFS than on any other file system. So I decided that it needed to test the creation of large numbers of files in a directory to be able to show how file systems such as ReiserFS outperform older file systems such as Ext2 and UFS."

Tima, это уже просто несерьезно. Эта ж тулзень (bonnie++) была _СПЕЦИАЛЬНО_ написана, чтобы использовать те фичи, на которых reiser fs выигрывает...

Специально, не специально это отдельный вопрос. А то что ReiserFS гораздо быстрее создает/удаляет/читает большие наборы файлов - факт. За это и боролись. И циферки на bonnie у тебя получались другие потому что так 100Mb файл пишется а не 200Mb как в bonnie++

(Пожимая плечами) Быстрее удаляет, Tima, именно _удаляет_. Это и есть ключевое слово. Вот они, Ваши 20 раз: http://www.namesys.com/cd_ben.html -- описание, как reiser fs "делает" ext2fs в двадцать два раза. Собственно, здесь http://www.namesys.com/lar_ben.html "акцент" на удаление очень хорошо заметен.

P.S. только какое это отношение имееет к реальной жизни? Что это за приложение, которое при нормальной работе _удаляет_ такое дикое количество файлов/каталогов? Универсальный патч? :)

Не подскажете - поддерживает ли reiser fs флаги Atime,Sync,Append,Immutable и.т.д. ???
Мне lsattr и chattr выдают :
lsattr: Inappropriate ioctl for device While reading flags on ./openssh-2.3.0p1

P.S. у меня reiserfs-3.5.24, kernel 2.2.16

то Shadow
Вот вот, про "Всё GNU отлично портируется" по подробней!
А то что slocale не идет. Да и другое добро не собирается, если нет
его зарание. (Solaris 7)

Вобщем, намного хуже портировать чем под Irix.


Eugene

Tima_ wrote : На ReiserFS создается файлы 3480 раз в секунду в секунду последовательно и 3356 произвольно против Ext2 173 раз последовательно и 177 произвольно. Итого производительность выше в 20 раз. Читаются файлы 29128 против 577 последовательно и 28722 против 740. Итого 50-40 раз. Удаляются файлы 5895 против 5657 и 5112 против 535. Итого - равно при последовательном в 10 раз лучше при произвольном. Угу. А теперь вспомним, что RaiserFS кеширует еще и создание/удаление файлов. И если файлики были небольшие, то за время создание=>запись=>чтение=>удаление до диска дело могло вообще не дойти. Чтобы все это действительно работало с диском, необходимо в бенче принимать дополнительные меры.

Dronov,
Быстрее читает Dronov, ЧИТАЕТ быстрее группы мелких и не совсем мелких файлов. (посмотри на bonnie приведеннов выше). А какое приложение занимается чтением мелких файлов? Правильно http / ftp / cvs сервера и любые ФАЙЛ сервера которые НЕ должны кэшировать дисковое i/o (IIS мазай). Причем разница между ReiserFS и Ext2 будет увеличиваться с увеличением нагрузки (частоты запросов и/или числа клиентов).
Это подтверждают даже Excel картинки с Namesys которые сравнивают ReiserFS с Ext2(1k блок) как будто кто то до сих пор использует 1k блок и как будто размер блока не сыграет на производительности.
Естественно прелестями fs НЕ воспользуются приложения кэширующие дисковое i/o или работающие с несколькими толстыми файлами (например Oracle). Кэшируют дисковое i/o большинство СУБД и proxy-caches. Сейчас большинство любителей кэширования i/o переходит на rawio разделы вообще. Например Inktomi 4 вообще не захочет устанавливаться на UFS/VFS раздел.

melechko,
Дополнительные меры были приняты. vmstat во время bonnie++ не показывал интенсивного обмена с RAM.

Вот так приходится заниматься пропогандой ReiserFS без намерения делать это.
Я полностью согласен с ifconfig о том что "недозревшее" состояние ReiserFS делают ее очень специфическим решением. Пережив 3 изменения формата журнала я каждый раз ругался матом при апгрейте ядра сопровождаюшегося экстренном бэкапом и полным востановлением раздела. С недавним решением включить ReiserFS в 2.4.1 ядро я робко надеюсь что больше изменений в формате журнала не будет.

Отвер Dronov, на твой вопрос о том какой скрипт очишает /tmp такой.
На системах не поддерживаюших tmpfs /tmp делается отдельным разделом чтобы при переполнении tmp не переполнялся / и система попадала в нестабольное состояние. Скрипт должен очишать /tmp полностью при загрузки и периодически удалять из /tmp не используемые файлы исходя из таблиц ядра которые можно получить например lsof. Своего рода tmp-watchdog. В /tmp должны записываться только систмные файлы. Никакие application сервера НЕ должны писать в /tmp - правило разделения временных системный и пользовательских файлов. Временные файлы приложений должны записываться также на свой отдельный раздел и размер раздела будет квотой для приложения. Вот так и живем, без квот.

В огороде бузина, а дядка в Киев уехал?

First of all, про bonne vs bonnie++: а что ж Вы, Tima, IIS не используете? А то вот здесь http://www.mindcraft.com/whitepapers/nts4rhlinux.html доказано, что он в 3 раза быстрее apache. :) Это я не в прядке личного "наезда", а для того, чтобы показать, что "синтетическим" benchmark'ом можно "доказать" все, что угодно. Вы просто bonnie погоняйте, а не bonnie++.

Вот, пожалуйста, симуляция сильно нагруженного mail server (с большим числом _удалений_): http://ftp.botik.ru/rented/namesys/ftp/pub/linux+reiserfs/gif/postmark/postma... Где там 20 раз? Там и 5-то нет.Причем вот здесь http://ftp.botik.ru/rented/namesys/ftp/pub/linux+reiserfs/gif/postmark/postma... даже и тех трех раз не видно. А с увеличением нагрузки, как это прекрасно видно здесь: http://www.namesys.com/db_ben.html, разница между ext2fs и reiser fs _уменьшается_ (что естественно, потому что на первый план выходят характеристики "железа", а не алгоритм fs).

Вот здесь http://www.namesys.com/cd_ben.html, здесь http://www.namesys.com/bn_ben.html, здесь http://www.namesydus.com/lar_ben.html, здесь http://www.namesys.com/lml_ben.html, здесь http://www.namesys.com/med_ben.html и, наконец, здесь http://www.namesys.com/mul_ben.html приведена прекрасная "разбивка" по типам операции (создание/поиск/чтение).

Из вышеприведенных URL видно, что resier fs имеет дикий выигрыш только на _удалении_ файлов. Вот Вы там можете увидеть прекрасных пример чистого _чтения_ (average file size 14k): find . -exec wc {} >&/dev/null \;. Только выигрыш от reiser fs там аж целых 1.07 раза. А на du -s * >&/dev/null (stat(2)) reiser вообще _проигрывает_. Это к вопросу о "http / ftp / cvs" занимающихся "чтением мелких файлов".