Вышел System Rescue CD 0.3.6

> В современных системах (да и не в современных тоже) узким местом является винт а не проц

Ой, да ладно. Вот, скажем, стоит у меня скромная машинка для серфинга по инету, на которой массив на линейку выдаёт 200-250 метров в секунду, а в нелинейку - так и не сильно чтобы меньше, и так ты думаешь, что на 100% загруженные работой с FS все 4 процессора - это типа великое добро, ага? Или наоборот, лимитирующей хренью становится процессор из-за сложнейшего и ветвистого, аки рога у бешеного оленя, мегакода за авторством джедаев из всем известной конторы, при том - массив становится круто недогруженным. Это, наверное, тоже хорошо?

Может стоит чем нибудь полезным процы в этот момент занимать, что очень здорово позволяет та же XFS? И вообще следовать правилу, "чем быстрее работает каждый элемент - тем быстрее система в целом", а не придрачивать скорости к самому "тормозному" элементу?

>Пресловутый же "выигрыш в 15%" что-то как-то расходится с моими собственным замерами на ядре 2.6.18, в коем оно адски тормозило даже в сравнении с reiser-3, притом - на тех самых мелких файлах, не сильно отставало в тормозах на крупных, и т.п.,

Ты уже забыл про сообщение одного парня, что чем старше версия ядра, тем медленее работает рейзер4 ? Правда страно, с учетом того, что исправляются баги.

> и под приличной нагрузкой валом сыпались ассерты с чудными именами. И вообще, раз есть выигрыш - значит кривые руки и не умеешь готовить ext*, не говоря уже о XFS/JFS и прочих кошерных файловых системах.

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

Я думаю вероятнее вторая причина.

Я объявил Линусу личную войну - он не включает рейзер4 в ядро, я не тестирую его новые ядра

:-)

>чушь: есть патчи с 2.6.11 по 2.6.21 (на .19-.21 - фактически одинаковые)

Откуда ты их берешь то ?

Спасибо, чет я тормознул...

>Раз одинаковые, то значит работа по развитию FS, правке багов и подгонке под требования Линуса, Мортона и прочей когорты мастер-джедаев не идёт - а, следовательно, ты сидишь уже 3 релиза подряд на крайне сырой поделке

вспоминая [ext3/mmap]-corruption (который у меня на рейзер4 почему-то не прокатил) и о "крайней сырости", принимая во внимание мнение признанных мастер-джедаев - как сташно жить!

>Пресловутый же "выигрыш в 15%" что-то как-то расходится с моими собственным замерами на ядре 2.6.18, в коем оно адски тормозило даже в сравнении с reiser-3, притом - на тех самых мелких файлах, не сильно отставало в тормозах на крупных, и т.п., и под приличной нагрузкой валом сыпались ассерты с чудными именами.

нечего сваливать собственные ошибки на других, у меня под 100%-й (не знаю что ты понимаешь под "приличной") нагрузкой ничего подобного никогда не выскакивало и данные не терялись даже при "жёстком" выключении питания. и сырцы линукса распаковывается почти в 2 раза быстрее, чем на ext3, с sync, конечно же. тормоза у тебя могли быть из-за того, что ты использовал SLOB вместо SLAB-аллокатора

>И вообще, раз есть выигрыш - значит кривые руки и не умеешь готовить ext*, не говоря уже о XFS/JFS и прочих кошерных файловых системах.

как ни готовь ты ext* - любой рейзер их порвёт в операциях (разве что кроме удаления) с небольшими файлами, про фрагментацию я вообще молчу (почитай на досуге про DancingTrees)

>Откуда ты их берешь то ?

ftp://ftp.namesys.com/pub/reiser4-for-2.6/

> Ты уже забыл про сообщение одного парня, что чем старше версия ядра, тем медленее работает рейзер4 ? Правда страно, с учетом того, что исправляются баги.

Дык, всё медленнее со временем работает, скоро суперкомп придётся для запуска тетриса собирать, ага. Ведузятнеги, вон, вообще в шоке уже.

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

Очень даже может быть, практика показывает, что ext/xfs - самая выигрышная и беспроблемная комбинация.

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

я такой же как и все люди этого призвания

>И gcc древний какой-то, уже 14 число на дворе, обновиться не пора? ;)

последние изменения касаются только sh-архитектуры, решил сэкономить пару киловатт на этой неделе :)

>Не пробовал на относительно стабильном софте сидеть? Говорят всё реально работает

в gcc-4.1 теперь принимаются только багфиксы (а их с момента выхода 4.1.2 набежало немало) - есть смысл обновляться и читая binutils-changelog - тоже есть, ядро 2.6.21 вроде будет стабилизироваться и там есть довольно полезные особенности (вроде DynTicks)

>и нет риска однажды возрыдать в великом горе, вырвать все волоса и начать звать маму в валокордином.

кто не рискует - тот не срывается в пропасть ;)

> вспоминая [ext3/mmap]-corruption (который у меня на рейзер4 почему-то не прокатил) и о "крайней сырости", принимая во внимание мнение признанных мастер-джедаев - как сташно жить!

Я тебе больше скажу - [ext3/mmap]-corruption у меня даже на ext3 не прокатил :)) А предыдущий страшный баг с XFS (что-то там про неудаляемые файлы) - не прокатил на XFS :) Чистой воды кармическая связь, видать я к энтырпрайс-среде переработал, красные глазюки слегка пригасли и отличные результаты во всех случаях достигаются только на ентерпрайз-эфэсках, в ущерб всему остальному :)

> нечего сваливать собственные ошибки на других, у меня под 100%-й (не знаю что ты понимаешь под "приличной") нагрузкой ничего подобного никогда не выскакивало и данные не терялись даже при "жёстком" выключении питания. и сырцы линукса распаковывается почти в 2 раза быстрее, чем на ext3, с sync, конечно же. тормоза у тебя могли быть из-за того, что ты использовал SLOB вместо SLAB-аллокатора

Ну, знаешь ли, в гробу я видал FS, что от тысячи и одной мелочи зависит, от внешних патчей и мильёна шаманств с молениями цифровым богам, жертвоприношениями девственниц кровавыми им же, а также прочим битием в бубен. И без того кошерное ядро патчить чёрти чем нужно. Тем более, что на amd64 CONFIG_SLAB=1 по дефолту и ниипёт.

"Приличная" - это когда дисковая подсистема становился узким местом. Потестим, конечно, даже интересно, что там изменилось и в какую сторону с древних времён.

> как ни готовь ты ext* - любой рейзер их порвёт в операциях (разве что кроме удаления) с небольшими файлами, про фрагментацию я вообще молчу (почитай на досуге про DancingTrees)

Ну да! А ты потести reiser-3 и ext3 на предмет работы с большими файлами - что-то как-то не видно, чтобы райзер кого-то там рвал, и даже вовсе наоборот - сливает вчистую (а удаление как раз оных быстрее происходит, чем на ext3) ;) С мелкими файлами - да, работает шустрее, но при том, врождённый порок райзера - процессорозависимость, и никуда от этого не деться.

>>Откуда ты их берешь то ?

>ftp://ftp.namesys.com/pub/reiser4-for-2.6/

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

>> Ты уже забыл про сообщение одного парня, что чем старше версия ядра, тем медленее работает рейзер4 ? Правда страно, с учетом того, что исправляются баги.

>Дык, всё медленнее со временем работает, скоро суперкомп придётся для запуска тетриса собирать, ага. Ведузятнеги, вон, вообще в шоке уже.

Увы ext3 то как раз за то же время стал работать существенно быстрее.

Т.е я рад за эту ФС, но столь очевидная кореляция повышения скорости её работы с понижением скорости работы рейзер4 явно убивает доверие к разработчикам ядра. При таком подходе они если и рыцыри, то только темные.

>Очень даже может быть, практика показывает, что ext/xfs - самая выигрышная и беспроблемная комбинация.

мне кажется темные рыцари овладели твоим сознанием, вернись на светлую сторону, пока еще можешь :-)

> Увы ext3 то как раз за то же время стал работать существенно быстрее. > Т.е я рад за эту ФС, но столь очевидная кореляция повышения скорости её работы с понижением скорости работы рейзер4 явно убивает доверие к разработчикам ядра. При таком подходе они если и рыцыри, то только темные.

Неа, светлые. Если EXT*/XFS/JFS работают быстрее и быстрее, а reiser4 - тормозится, то тараканы явно не у разработчиков ядра. О чём уже сто лет талдычится Гансу и компании. И почему они в пролёте по жизни.

> мне кажется темные рыцари овладели твоим сознанием, вернись на светлую сторону, пока еще можешь :-)

Да не, 100%, меня лично Соломон Моисеич в своё время уму-разуму учил, о какой тёмной стороне может идти речь? Всё кошерно и как полагается :)

> так что не надо ля-ля :)

Это относилось к тому, что разницы между патчами для .19 .20 и .21 нет. Патчи от .19 на .20 накладывались, но не собирались, а не то, что не собирается .21 с патчем для .21. А так у меня самого сейчас .21.5 + ворох патчей + четвёртый рейзер в полном порядке.

После воспоминаний о виндовом рековери консоле по телу мелкая дрожж. %)

>Я просто перевел экран загрузчика :) а в списке пакетов есть sys-fs/zfs-fuse-0.4.0_beta1

А там через FUSE идёт.., я думал уже нативную курят..)

> У меня на / reiser4: быстрее reiserfs на ~15%

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

>угу. если раздел активно используется на запись-чтение, потерпи пол года. потом IO начнет неимоверно проседать, из-за дикой фрагментации, которой подвержены как reiser3, так и reiser4.

Ну - у меня reiser3 юзается на чтение/запись уже больше года и ничё, никакой фрагментации..)

На червёрке влияние фрагментации очень заметно.

> Пресловутый же "выигрыш в 15%" что-то как-то расходится с моими собственным замерами на ядре 2.6.18, в коем оно адски тормозило даже в сравнении с reiser-3, притом - на тех самых мелких файлах, не сильно отставало в тормозах на крупных, и т.п., и под приличной нагрузкой валом сыпались ассерты с чудными именами.

У вас CONFIG_REISER4_DEBUG=y , а это сильно тормозит работу, особенно с мелкими файлами. Сообщения об ассертах желательно посылать в соотв. лист

> Накладываться-то накладываются, да вот только на .20 и .21 потом не собираются, так что не надо ля-ля...

Как так не накладываются ?!

> Ну - у меня reiser3 юзается на чтение/запись уже больше года и ничё, никакой фрагментации..)

А у меня reiser3 стал реально тормозить как раз где-то после полугода активного r/w(гентушные емержи). Так что сраный дико фрагментирующийся рейзер - в топку!

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

> У вас CONFIG_REISER4_DEBUG=y , а это сильно тормозит работу, особенно с мелкими файлами. Сообщения об ассертах желательно посылать в соотв. лист

Ананимус, ну Вы-то хоть херню не порите, чай коллективный разум ЛОРа а всё туда же... :\

Какой, к дьяволу DEBUG, неужели просто нельзя поверить, что по дефолту без биения в бубен, релизная версия райзера-4 дико тормозит в сравнении с ext*/xfs на платформе amd64? Когда дерево ядерных сорцов распаковывается в разы дольше, а межверсионные (+1 patchlevel) патчи накладываются вообще столько времени, что поседеть можно - то это явно не происки злых духов, а кривая настойка по дефолту и общая неотлаженность ФС.

Ибо сила - в компромиссе.

Добрый день, господа!

Я попробовал этот диск в производственной среде (перелопачивание винчестера, набитого разделами Линукса разного формата). Великолепно, если бы не одно "но", о котором хотел бы сообщить всем заинтересованным лицам.

У меня аппарат P4-3000 (HT), память 1 ГБ, видео Radeon 9200 Pro (RV280) 256 МБ, жесткие диски разные, монитор NEC 1970V. Описываемый компакт-диск великолепно загружается в текстовом формате, но при выдаче команды startx экран монитора гаснет, и на нем появляется сообщение аппаратуры монитора "вне допустимой зоны", т.е. система неправильно определяет по DDC параметры кадровой и строчной развертки для монитора. На версии 0.3.2, которую я пользовал до того, такого безобразия не было, хотя при запуске иксов по умолчанию полное разрешение монитора не определялось.

Рекомендую перед запуском иксов выдать команду xorgconfig и указать такие параметры видеоподсистемы, чтобы изображение появилось наверняка.

Всем удачного рескьюсидирования.

> Как так не накладываются ?!

Странно, писать умеешь, а читать нет...

> монитор NEC 1970V. Описываемый компакт-диск великолепно загружается в текстовом формате, но при выдаче команды startx экран монитора гаснет, и на нем появляется сообщение аппаратуры монитора "вне допустимой зоны", т.е. система неправильно определяет по DDC параметры кадровой и строчной развертки для монитора.

А теперь осознай, что понятия "кадровой и строчной развёртка" для LCD мониторов не имеют смысла. Другой вопрос - "подключение по D-SUB", но таких джедаев-ретроградов нынче мало осталось.

> Какой, к дьяволу DEBUG, неужели просто нельзя поверить, что по дефолту

Какой еще к черту дефолт при сборке ядра? Достали, блин эти фефочки которые мануал на английском прочитать не умеют..