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

Ухх ты! Как все просто-то! Как же я глупый не догадался-то сам, что "каждому приложению по разделу" (прямо коммунизм какой-то). Только, как и коммунизм, оно плохо работает. Вот у меня сейчас крутится около 10 приложений, причем не следующей неделе как минимум три из них будут удалены, а после нового года как минимум 8 новых будет за'deploy'ено. Это что ж мне, постоянно переразметкой дисков заниматься? А если завтра средний размер данных, обрабатывемых приложением, изменится с 10K до 10M (вот, кому-то захочется ту самую "важную презентацию на 10M" туда запихнуть)? Или, например, на той неделе количество пользователей, использующих приложение возрасло в 2 раза -- соотвественно теперь этому приложению надо в два раза больше места. Не говоря уже о том случае, когда приложению надо временно "выпрыгнуть" за свои квоты (ex: emergency push _всего_ content на web server).

P.S. Про "системные файлы" я вообще не понял. У меня таких нет. Логи различных серверов есть, различные spool'ы есть, staging area есть, DB storage есть, /tmp, в конце концов, есть, а вот "системных файлов" у меня нет.

Dronov,
Что Вы результатами бенчмарков с Namesys заладили?
Вы хотябы имеете представление сколько им лет? :)
Я их в первый раз увидел 2 года назад.

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

Bonnie++ читает 30 файлов в длинном цикле и показывает что Reiserfs быстрее в _50_ раз. Это на современном ядре и современной Reiserfs

Dronov,
Это не коммунизм, это капитализм.
А вот где 10 приложений крутится, 3 снимутся а 8 добавится причем системных файлов не существует и приложение резко захочет использовать в 10 раз больше места, там даже не коммунизм, там пионер-лагерь.
С пионер-лагерем я пообещал себе в спор не вступать - слишком много свистят.

Tima_ Не сочтите за идиотский вопрос, но позвольте >"читает 30 файлов в длинном цикле и показывает что Reiserfs быстрее в _50_ раз" читает куда? Мне, например. непонятно. Если вы имеете ввиду в /dev/null то это задача имеет чисто теоритический интерес, если с блина на блин то позвольте поинтересоваться, если у меня на ext2 копирование с диска на диск приблизительно со скоростью 10Mb/s то на reiserfs должно быть 500Mb/s ? Сами понимаете бред. Если имется ввиду чтение данных приложением, то позвольте узнать каким приложением? А лучший benchmark это собственный опыт, а он показывает, что Reiserfs быстрее, но во-первых не намного, а во-вторых пока еще недостаточно стабильна. И, как кто-то уже до меня заметил, картинки и тесты на www.namesys.com не меняют потому что менят собственно нечего. Другого обьяснения нет, если вы его знаете поделитесь с народом плиз, неужели вы думаете что им "вломы" сделать новые тесты или страницу заново оформлять:)

ifconfig,
пишет на раздел где установленна и читает из раздела.
Результат читается так. Цикл чтения 30 фалов с ext2 прошeл 577 раз в секунду, и 29128 раз с reiserfs.
Собственный опыт говорит о том что reiserfs ощутимо убыстряет процесс дел, очень сокращает время загрузки (сколько времени нужно fsck чтобы оттестировать 30Gb раздел?), более устойчива. Конечно есть проблеммы с законченностью дизайна, как я уже согласился, но выбора особого нет. В 2.4 появится xfs. Вот ей то reiserfs и заменим.
А Namesys не изменяется по той же причине что и GNU.org - лень и загруженность работой над кодом а не над показухой вроде вэб сайта. Лучше дело делать а не пальцами кидаться.

Пионерлагерь? Странно, а наши аналитики считают, что это нормальный процесс обновления программного обеспечения, призванный повысить эффективность работы. А, понял! Tima, у нас не 10 человек, не 100 и, даже, не 1,000. Так что пара десятков приложений -- это вполне нормально. Ex: приложение для marketing group, приложение для web design group /это вообще тихий ужас/, приложение для sales group, приложения для customer support groups /их несколько, по количеству основных продуктов/, несколько приложений генерящих customized reports, etc., etc., etc.. Даже если брать только основные группы -- уже несколько десятков приложений наберется. Плюс разделение на регионы... Боюсь, Вы полохо представляете себе разнообразие требований к ПО в большой корпорации.

Tima, мне очень жаль, но пока на "пионера" похожи Вы: "Цикл чтения 30 фалов с ext2 прошeл 577 раз в секунду, и 29128 раз с reiserfs". Посчитайте _объем_ данных, которые надо передать по шине, чтобы прочитать/записать данные из 30 файлов 29128 раз с секунду и сравните с цифрой, которую Вы привели для своего винчестера (и с объемом памяти на Вашем компьютере, чтобы понять, что отговорка "оно все в cache влезло" не работает). Потом посмотрите в доку на bonnie++ и с удивлением узнайте, что речь идет о 30K (30720) файлов(-лах?).

А вот описание того, что _на_ _самом_ _деле_ делает bonnie++:

"For the random tests we create the files in an order that will appear random to the file system (the last 7 characters are in numeric order on the files). Then we stat() random files (NB this will return very good results on file systems with sorted directories because not every file will be stat()ed and the cache will be more effective). After that we delete all the files in random order."

Вот видите Dronov, стоит почитать доки как сразу становится понятным о чем я говорю.
Суть остается той же - reiser быстрее.
А что до работы в большой компании так в капитализме принято занимать отдельно взятую машину одним важным делом. А не нагружать один комп 10ю задачами для более чем 1000 человек.
Маркетинг и сейлз радуются десятком своих Win2k (наверное) с Exchange, Act! и тому подобным (для этого есть Windows группа). Кастомер суппорт занимает кастомер суппортом.
А вот 4000 Соларисов и несколько сотен Linux это дело Systems Administration группы.
1000 Соларисов работает на хостинге (несколько машин для одного кастомера) 2000 машин работают кэшами и 1000 занимается streaming.
По одному проекту на машину заметьте.
Если машина DNS сервер, то она только DNS и занимается. Если машина кэш - то она мэйл сервером не работает. И на машине с Oracle работает только oracle.
Планировуется все тщятельно. Цикл отлажен.
Поступает заказ - вырабатываются требование - имплементируется - тестируется - внедряется.
В ходе внедрения продумывается:
Какие машины будут задействованы,
Куда временные файлы будут падать продумывается,
Нужные разделы делаются,
Обмысливается куда будут писатся логи и как они будут обрабатыватся,
Решается кто и как будет следить за машинами.
Вот так и работает большая организация в которой я работаю.
Самое главно заметьте - нигде не присутствуют КВОТЫ (о чем собственно и был разговор).
Целосность данных поддерживается четырьмя простыми правилами.
1. Системные и user бинарники держатся раздельно.
2. Системные и user логи держатся раздельно.
3. Системные и user временные файлы держатся раздельно.
4. Критические статические пользовательские данные держатся раздельно.
Меня к такой практике приучили люди которые в 92-97 году содержали всю intranet Cisco.
Как по Вашему мнению Dronov, Cisco это большая компания?

Удивляюсь, за что американцы Тиму все еще держат. У нас на фирме за такой
ламерский базар поперли бы на третий день. Вот это: "http / ftp / cvs сервера
и любые ФАЙЛ сервера которые НЕ должны кэшировать дисковое i/o". Да они маму
родную продадут, чтоб иметь возможность кешировать. Ухищрения разные придумывают,
memmap, ramdisk и т.д. Не Тима, в Россию, если ты русский, тебе назад путь заказан.
Здесь такие ламеры не нужны.

Ха, anonymous,
Скажу только - наивные у тебя представления о кэширование.
В M$.ru тебя работать точно взяли бы. IIS разрабатывать.

Weekend заканчивается - пора и трепню заканивать.
Cheers.

Ндаааа, конечно, рассуждая о "целостности системы", абсолютно на надо понимать, что прочитать 30720 файлов 29182 раз в секунду Ваше "железо" просто не позволяет... Зачем вообще что-то понимать? Тест-то какие-то циферки выводит, вот и ладно. Зато есть время неразумных поучить, как им производство организовывать. А то они, бедные, двадцать лет филиал на Марсе открыть не могут, один M$ с w2k туда пробился. :)

Потешил старика, спасибо.

По моему Тима хвастается, что у него rm -rf / делается быстрее, чем у всех ;)

2Dranov:
>прочитать 30720 файлов 29182 раз в секунду Ваше "железо" просто не
>позволяет
Конечно, не позволяет! Эти "циферки" показывают, что скорость
ограничена только "железом". Вроде бы неплохо...

Led.

Ага, еще один. Ну хоть Вы-то не будете мне объяснять, что мне надо срочно заменить наш кластер с app server на w2k с exchange, как это делал Tima? :) Кстати, теперь-то я понимаю, почему у Cisco дела пошли в гору после 97 года: http://quote.netscape.com/chart/Quote.tibco?view=chart&symbols=CSCO&q...

Я осознаю, что английского Вы не знаете, и прочитать описание теста, которое я сюда запостил Вы не можете. Я также прекрасно понимаю, что этот тест Вы сами не гоняли и тот факт, что там обращения к диску отсутствовали вообще Вас смутить не мог. Но Вы хотя бы 4 класса средней школы закончили? Он сказал, что трансфер его винчестера 20Mb/sec Вот посчитайте _размер_ каждого из этих файлов, чтобы их можно было за секунду прокачать 30720*29182 штук по каналу в 20Mb. Для тех, кто совсем ничего не знает: в одном Mb -- 1024*1024 bytes.

Тут вот человек хмыкнул и предложил супер-тест, который раз и навсегда докажет, что linux/reiser fs/apache/samba -- rulez:

main() { printf("You linux box is 73 times faster"); }

Скомпилируйте и запускайте в свое удовольствие. :)

Dronov,
Да успокойтесь Вы.
Спасибо вам большое за весь ваш запостченный текст.
Я узнал из него много нового и полезного для себя.
Бенчмарки с Namesys 2х летней давности,
Рассуждения о надобности квот на /tmp,
Обзор приложений работаюший на серверах многорегиональных российских
компаний,
И многое многое другое.
Еще раз спасибо.

Вы уж извините меня ленивого Dronov, что усталвши вам по третьему разу
одно и то же я не посмотрел в spec bonnie++ и сделал грубейший вывод
из строчки ее логов
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
что это она читает 30 файлов в цикле.
Спасибо большое за вашу бдительность и неленивось в который раз
поднять эту тему и правильно заметить что bonnie++ создает 30K фалов,
делает stat и удаляет их.

Позвольте в качестве раскаинья в ведении людей в смущение привести пример копирования.
/space - ReiserFS, /opt - Ext2, /export - Ext2, /export/src/kernel -
собранное ядро Linux.
[root@nautilus /space]# time cp -R /export/src/kernel .
0.33user 3.08system 0:40.11elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31497major+203minor)pagefaults 0swaps

[root@nautilus /opt]# time cp -R /export/src/kernel .
0.45user 8.76system 1:06.33elapsed 13%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31496major+203minor)pagefaults 0swaps

Естественно, ReiserFS по скорости обгоняет Ext2 всего лишь в ~1.65 раза
на этом тесте и это в который раз подтверждает вашу мысль о том что
ReiserFS совсем не стоит труда и внимания.

Зачем такие сложности, компилить чего-то, вероятно это не всем по зубам... можно проще $echo "Yours linux box as faster as possible and one is faster computer around the World!!" Можно в цикле запустить, щоб круче было и сиди себе радуйся от своей крутости. А если серьезно, то перед тем как верить всяким тестам нужно немного разбираться в том что собственно этот тест делает и возможно ли это "физически"

Не подскажете - поддерживает ли reiser fs флаги типа Immutable и.т.д. ?
Или никто не знает ?

Вчера посмотрел на графики результатов бенчмарков ex2 vs reiserfs
При ext2 с 1к на инод при невысокой нагрузке reiserfs быстрее раза в полтора.
При относительно большой нагрузке результаты практически уравниваются.

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

RFS крута тем, что записи о файлах в каталоге храняться в b-дереве. Для поиска файла с данным именем идет поиск по btree, а не линейный поиск по всем записям о файлах. Попробуйте создать 100K файлов (вполне нормальная ситуация для мейл-серверов) в одном каталоге, и поудаляйте произвольный файл или просто даже почитайте файл с произвольным именем. На не-RFS скорость таких операций будет жутко медленной. А журналирование - это дело десятое (если деньги на ups есть или если вы не разработчик ядра). Естественно при записи в один большой файл журналируемая FS медленне не-журналируемой. При чтении большого файла - должно быть одинаково.

hvv
В ReiserFS не только запись каталога, но и сам файл (если невелик) хранится в записи каталога.
Отсюда выходит:
1) Скорость операций поиска в каталоге.
2) Скорость чтения множества небольших файлов (squid, gcc и т.п.)
3) Отсутствие сколь-нибудь заметного удара по производительности, несмотря на журналирование.

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

Диаграмки показывают, что под нагрузкой выигрыша нет, или почти нет

единственный смысл в журналируемой системе --- быстрый подъем сервера имеющего большое дисковое пространство после перезагрузки (перезагрузка может имееть любую причину :) у райзер-фс несовместимость пока практически со всеми файлсерверами. когда ее полностью доведут ее можно будет использовать на серверах. а сейчас только рабочки с не требовательностью к особенностям фс :) Петров

Тима, мое ядро гораздо больше твоего (2.4.0-t10) и при копировании
с ext2 на ext2 я получаю всего 38 сек. Диск IDE ata66, проц PIII 600, 128 RAM.
У тебя кажется похожая техника? Ну тогда ext2 все равно быстрее получается.
На всякий случай - `du -s /usr/src/linux` показывает 109236 (109Mb)

> при копировании
> с ext2 на ext2
Копировании чего?
В нормальной серверной системе соотношение запись чтение 1:10

Попробуй сам тестик сделать - создай тысяч 50-60 файлов случайного (random подойдёт) размера от пары кило до 10 мег, да 1000 раз считай из случайного файла случайное кол-во байт (от кила до размера файла, начиная с случайной позиции)
Это ни на что не претендует, но хоть-что-то покажет.
Пользователи, знаете ли с приложениями работают а не архивы копируют.

> du -s /usr/src/linux` показывает
Сделай лучше df -i на ext2 и на Reiser.
Сравни результаты :))))))

http://www.noosphere.ru/download/takeittux.jpg Не, ну на самом деле.

> Копировании чего?

Баран, читай выше. Это был ответ на тест Тимы.

to ужасная_собака:

> Попробуй сам тестик сделать - создай тысяч 50-60 файлов случайного (random подойдёт)

Опять баран. Если сервер в короткое время создает 50-60 тыс файлов, то это явно не случайно ;-)
Более искусственного теста, чем приведенный тобой придумать трудно.

Анонимус, едрить-колотить!
> Если сервер в короткое время создает 50-60 тыс файлов, то это явно не случайно

Кол-во - да, велико, но суть вполне характерна для кэширующего прокси или почтового сервера с maildir.

Ну а если просто охота увидеть разницу - запусти GIMP на ext2 и на Reiser :)

Мда ... Рановато еще журнальную FS ставить . В первых заколебало патчить ядро во вторых samba на ReiserFS тормозная (не надо про настройку sambы - такая же связка работает на ext2 в три раза быстрее). Поэтому - кто хочет проблем на голову - пусть ставит Linux + RFS - такая связка однажды попортила файлы БД бухгалтерии. IMHo сейчас еть промышленного класса Solaris (от 2.5 до 8-ки) который работает как черт и ни разу не понадобилось прибегать к restore backup.

Вот блин, для фом неверующих свежий dbench тест. Он отчетливо показывает разницу
между 2.2.х и 2.4.х для ext2fs. А разница - 3 (три) раза. Поэтому, когда
кто-то орет, что reiserfs так круто уделывает ext2, пусть сделает поправку
на эти данные.

Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Blocksize=4K
Test: dbench 48

Kernel Throughput Elapsed Time
------ ---------- ------------
2.2.16 3.1 MB/sec 33 min 53 secs
2.2.18 2.8 MB/sec 38 min 10 secs
2.2.19-pre3 2.7 MB/sec 39 min 44 secs
2.4.0-test12 7.3 MB/sec 14 min 32 secs
2.4.0-test13-pre4 9.5 MB/sec 11 min 06 secs
2.4.0-test13-pre5 10.8 MB/sec 9 min 48 secs

Dbench was written by Andrew Tridgell to measure disk performance under
simulated samba network traffic load. The '48' means it's simulating
the file access patterns of 48 network clients, all doing heavy io at
the same time.

For anyone interested in checking these results on their own hardware,
dbench is available at:

ftp://samba.org/pub/tridge/dbench/dbench-1.1.tar.gz

Ну и?
Интересные выводы делает народ...
Если в 2.4 какой-то из тестов получил ускорение на ext2, то почему-то думают, что на ReiserFS он будет работать хуже :)
> В первых заколебало патчить ядро
пользуйтесь приличными дистрибутивами и не конопатьте людям мозги.

анонимусы - что с них взять...

Специально для ужасной собаки (aka AffreuxChien) даю новый тест. На этот раз сравнение reiser и ext2.

Some more numbers to consider:

7.3 MB/s 54.7s user 159.6s system 25% cpu elaspsed 14:21.9m
reiserfs on hda whick gets 16.1 MB/s from hdparm -t

9.7 MB/s 51.6s user 78.3s system 19% cpu elaspsed 10:50.8m
ext2 on hdb which gets 10.6 MB/s from hdparm -t

both drives are udma33. The sytem is a K6-III 400 with 128m running:
2.4.0test13pre6 + reil #2 + drm fix + reiserfs 3.6.23

Think ext2 is doing pretty good. I have seen comments that imply dbench
does not show reiserfs at its best - they favor the bonnie suite.

Как вы не поймете! ext2 is fucking rock solid and also so fast on recent kernels!
Терпеть не могу, когда ламерье хвастается reiser'ом. Глюк на глюке, плюс
сверх сомнительное превосходство по скорости, которое подтверждается только
на тестах 2-х летней давности.

анонимус,
Во первых - 2.4 ещё нет в природе.
Во вторых - прогнал бы апачий бенч для разнообразия
А в третьих - надёжность это главное, посему до выхода в свет ext3 xfs и jfs - сравнивать просто не с чем.
Выйдет 2.4 (это будет скоро) - можно будет смотреть. Тогда я сам прогоню этот тест, но как человек в здравом уме и рассудке я нестабильное ядро ставить никуда не буду.
А пока - 2.2.18, может Reiser и медленнее, но dayly maintance идёт на Riser в 2 раза быстрее.

Это для anonymous который спрашивал.
du -sk /export/src/kernel
112876 /export/src/kernel (112Mb)
Ядро 2.2.18, проц PIII(500)Katmai и UDMA33 hdd.

Рекомендую попробовать fsck на 60Gbом диске под ext2.
Если переживете значит у вас нервы много лучше моих.

Я. ;-)
Нарадоваться не могу. Линус прав: RH - для криворуких маздайщиков. Типа того, что есть некая вероятность того, что КРИВЫЕ_РУКИ+КРИВОЙ_ДИСТРИБУТИВ дадут что-то ну хоть сколько-нибудь стабильное... Если, разумеется, выражение "стабильность" можно применить к RH. (В чём я лично ОЧЕНЬ сомневаюсь.)

K voprosu okolichestve failov kotorie nado sozdat'dla testa. :). Kompania: Telecom Personal, Argentina. Ofisov v Buenos Airese: 12 krupnih (polnost'u zdanie, 15-20 etajei x 100-200 chel na etaj), 1000 s hvostikom tochek (2-3 rabochih mesta). Ofisov po strane: a her ego upomnit. okolo 10000. tochek, plus 1 krupnii v kajdoi stolice provincii i bol'shom gorode (okolo 20). Vse seti zavazanni na klaster pod Solaroi. Kajdii pol'zovatel' pod NT imeet katalog "Personal" kotoraia hranitsa na visheupomanutom klastere i podkluchaetsa pri zagruzke kak local'naia. Vopros. Skol'ko etih failovih operacii v sekundu proizvoditsa userami v edinicu vremeni, esli uchest', chto vse otdeli rabotaut s etim klasterom, Web, milo etc. tam je. Eshe voprosi? ironCat. (zabil parol') PS Sorry za translit, NT russkii ne derjit. k.