| 1.4, fresco (?), 16:30, 06/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я не ошибся -- reiser4 действительно будет включена?!
Действительно хорошая новость!
| | |
| 1.5, fresco (?), 16:40, 06/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А, понял.
Включение reiser4 пока только обсуждается. В примечании к этому набору патчей сказано, что эта ФС пока находится на раннем этапе развития и нуждается в развернутом тестировании производительности. Скорее всего -- merging будет отложено, как и раньше.
Не любит ее Мортон, что поделаешь... | | |
| |
| 2.6, pavlinux (??), 17:22, 06/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 > Не любит ее Мортон, что поделаешь...
Мортон, то как раз и с пониманием относится..., а вот Пингвин-Торвальдс как раз наоборот
говорит что reiser4 - "... not a Linux kernel style programming"
| | |
| |
| 3.7, fresco (?), 19:36, 06/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Напротив, Торвальдс по поводу reiser4 давно не высказывался. И к стилю программирования претензии давно не выдвигаются -- в ход пошли гораздо более серьезные аргументы. Главные идеолги "невключения" reiser4 -- Мортон и Кокс.
В общих чертах суть их недовольства заключается в том, что reiser4 не только мало использует generic-код, предназначенный для автоматизации рутинной работы, наличиствующей почти во всех ФС (типа generic-read, generic-write, тесно интегрированные со страничным и блочным кэшами), но и своими плагинами вносит в ядро избыточную функциональность, уже реализованную в слое VFS. Где-то они, конечно, правы. Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.
По-русски говоря -- они уперлись лбами и уже больше года дале не движется. | | |
| |
| 4.8, universite (ok), 19:43, 06/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >По-русски говоря -- они уперлись лбами и уже больше года дале не
>движется.
Самый простой способ - сделать две ветки ядра :)
С reiser4 и без.
| | |
| |
| 5.10, pavlinux (ok), 22:50, 06/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> сделать две ветки ядра
Ага, Щщщасс, ... скорее пингвины станут перелётными птицами... | | |
|
| 4.11, sauron (??), 07:31, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы
>написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут
>в основном благодаря отказу от их использования.
Тут вот возникает вопрос не оптимально для reiser4 или все же в общем случае? Если только для reiser4, я бы тоже был против включения такого кода в ядро. Не взирая насколько он хорош это может грозить проблемами после включения кода в ядро.
| | |
| |
| 5.12, Zlobec (?), 09:33, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не оптимален а второй оптимален но не стандартен не есть хорошо для ядра в котором и так полный бардак.
Вобщем Рейзеру надо не выпендриваться и выложить код под BSD ))
| | |
| |
| 6.16, sauron (??), 11:32, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не
>оптимален а второй оптимален но не стандартен не есть хорошо для
>ядра в котором и так полный бардак.
Вот вот. Потом где гарантии, что оптимальное для reiser4 будет оптимально для остальных файловых систем?
| | |
|
| 5.14, fresco (?), 11:08, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых систем. Но если он ограничивает не только свободу мысли разработчика, но и функциональность будущей ФС?
Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы из ФС, но что тогда отанется от reiser4?
Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и, как бы это сказать... слишком много на себя берет, что ли. По логике -- надо переделать всю VFS, но этот вариант еще хуже, чем включение избыточного кода reiser4.
Словом -- это действительно тупик, и человеку, который найдет из него приемлемый выход, я лично выкачу ящик пива :) | | |
| |
| 6.15, sauron (??), 11:31, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых
>систем. Но если он ограничивает не только свободу мысли разработчика, но
>и функциональность будущей ФС?
Может в таком случае стоит заняться предложениями по модификации generic-кода VFS ?
>Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного
>кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и
>все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы
>из ФС, но что тогда отанется от reiser4?
Но делать это в обход стандартного API ядра не совсем верно не так ли? Плюс это может сказаться на стабильности как файловой системы так и ядра.
>Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и,
>как бы это сказать... слишком много на себя берет, что ли.
>По логике -- надо переделать всю VFS, но этот вариант еще
>хуже, чем включение избыточного кода reiser4.
Этот вариант лучше чем включение избыточного кода reiser4. Да более трудоемко но более верно.
>Словом -- это действительно тупик, и человеку, который найдет из него приемлемый
>выход, я лично выкачу ящик пива :)
Наиболее верным вариантом будет предоставить новый код VFS с учетом уже включенных FS. А уже затем включать reiser4 с использованием нового VFS. Прогибаться под ядро должна файловая система, а не ядро под файловую систему.
| | |
| |
| |
| |
| 9.19, fresco (ok), 13:14, 07/06/2006 [^] [^^] [^^^] [ответить] | +/– | Не согласен Обсуждаемый generic-код был написан специально для ext3 и только д... текст свёрнут, показать | | |
|
|
|
| 6.20, DeadMustdie (??), 13:40, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Хм... XFS в среднем не медлительнее Reiser4. И присутствует в ядре.
Сильно подозреваю, что в оном XFS используются рекомые "устаревшие"
и "много на себя берущие" примитивы. Выводы? | | |
| |
| 7.21, fresco (ok), 13:58, 07/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
XFS, в среднем, ощутимо _медлительнее_ reiser4.
Только не надо требовать бенчмарков -- их по сети полно.
Если интересно, могу скинуть исходники свих тестов. | | |
| |
| 8.23, sauron (??), 14:42, 07/06/2006 [^] [^^] [^^^] [ответить] | +/– | Хорошо давайте теперь переведем reiser4 на generic io и сравним Иначе не коррек... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.25, funny_falcon (?), 19:28, 07/06/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем более reiser3. Может то, что я видел, устарело? Может кто-нибудь дать линк на свежее сравнилово, где reiser4 рвет всех? | | |
| |
| 2.28, xu (?), 08:26, 08/06/2006 [^] [^^] [^^^] [ответить]
| +/– | |
А самому потестить никак? Тоже ядро патчить лень, да проги писать руки не доходят? | | |
| 2.33, pv (?), 22:26, 18/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем
>более reiser3.
Насколько я знаю, reiser4 намного прожорливее, когда речь идёт о процессорном времени. Посмотри на описания аппаратного обеспечения, где тестируются файловые системы.
Полгода назад я тоже искал тесты. Все найденные тесты были проведены на Celeron 500 и ему подобных, потому рейзер и показывал не лучшие результаты (загрузка процессора ~90-95%). При запуске на AthlonXP 3000+ загрузка процессора составляла порядка 15-20%. Для десктопа приемлемо. | | |
|
| |
| 2.32, Radeon (?), 15:14, 10/06/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >>Reiser4 жжот полюбому!
Подарить огнетушитель и лекарство от ожегов? | | |
|
|
