В обновлении Linux ядра 2.6.16.20 (http://www.kernel.org/) исправлен (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.20) ряд не имеющих отношения к безопасности ошибок, связанных с работой libata, ieee1394 sbp2, ipw2200, x86_64, psmouse (http://bugs.gentoo.org/130846), PowerMac suspend-to-disk, Cpuset, Altix.Andrew Morton представил список патчей (http://kerneltrap.org/node/6681) претендующих на включение в ядро 2.6.18.
План развития 2.6.18 будет обсуждаться во время двухдневной поездки Andrew Morton в Азию, в связи с чем к Линусу Торвальдсу обращена просьба подождать с анонсом релиз-кандидата 2.6.18-rc1 на неделю. Соответственно 2.6.18-rc1 должен появится примерно 17-24 июня.
Из нескольких сотен претендующих для переноса патчей (http://kerneltrap.org/node/6681) можно отметить: чистка лишнего в заголовочных файлах ядра, reiser4, klibc, ieee1394, новый ACX1xx драйвер для беспроводных устройств, per-task statistic metrics, clocksource management infrastructure, smpnice, swap prefetching, priority-inheriting futexes, ecryptfs, utsname virtualization, readahead, statistics infrastructure и код для контроля блокировок.URL: http://kerneltrap.org/node/6681
Новость: http://www.opennet.me/opennews/art.shtml?num=7680
Поистине строительство Вавилонской башни. :(
ты сторонник микрокернельного подхода?
О! Reiser4 наконец. Жду!
Её уже год, если не больше, включают...
Я не ошибся -- reiser4 действительно будет включена?!
Действительно хорошая новость!
А, понял.Включение reiser4 пока только обсуждается. В примечании к этому набору патчей сказано, что эта ФС пока находится на раннем этапе развития и нуждается в развернутом тестировании производительности. Скорее всего -- merging будет отложено, как и раньше.
Не любит ее Мортон, что поделаешь...
> Не любит ее Мортон, что поделаешь...
Мортон, то как раз и с пониманием относится..., а вот Пингвин-Торвальдс как раз наоборот
говорит что reiser4 - "... not a Linux kernel style programming"
Напротив, Торвальдс по поводу reiser4 давно не высказывался. И к стилю программирования претензии давно не выдвигаются -- в ход пошли гораздо более серьезные аргументы. Главные идеолги "невключения" reiser4 -- Мортон и Кокс.В общих чертах суть их недовольства заключается в том, что reiser4 не только мало использует generic-код, предназначенный для автоматизации рутинной работы, наличиствующей почти во всех ФС (типа generic-read, generic-write, тесно интегрированные со страничным и блочным кэшами), но и своими плагинами вносит в ядро избыточную функциональность, уже реализованную в слое VFS. Где-то они, конечно, правы. Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.
По-русски говоря -- они уперлись лбами и уже больше года дале не движется.
>По-русски говоря -- они уперлись лбами и уже больше года дале не
>движется.Самый простой способ - сделать две ветки ядра :)
С reiser4 и без.
> сделать две ветки ядраАга, Щщщасс, ... скорее пингвины станут перелётными птицами...
>Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы
>написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут
>в основном благодаря отказу от их использования.
Тут вот возникает вопрос не оптимально для reiser4 или все же в общем случае? Если только для reiser4, я бы тоже был против включения такого кода в ядро. Не взирая насколько он хорош это может грозить проблемами после включения кода в ядро.
Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не оптимален а второй оптимален но не стандартен не есть хорошо для ядра в котором и так полный бардак.Вобщем Рейзеру надо не выпендриваться и выложить код под BSD ))
>Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не
>оптимален а второй оптимален но не стандартен не есть хорошо для
>ядра в котором и так полный бардак.
Вот вот. Потом где гарантии, что оптимальное для reiser4 будет оптимально для остальных файловых систем?
Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых систем. Но если он ограничивает не только свободу мысли разработчика, но и функциональность будущей ФС?Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы из ФС, но что тогда отанется от reiser4?
Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и, как бы это сказать... слишком много на себя берет, что ли. По логике -- надо переделать всю VFS, но этот вариант еще хуже, чем включение избыточного кода reiser4.
Словом -- это действительно тупик, и человеку, который найдет из него приемлемый выход, я лично выкачу ящик пива :)
>Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых
>систем. Но если он ограничивает не только свободу мысли разработчика, но
>и функциональность будущей ФС?Может в таком случае стоит заняться предложениями по модификации generic-кода VFS ?
>Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного
>кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и
>все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы
>из ФС, но что тогда отанется от reiser4?
Но делать это в обход стандартного API ядра не совсем верно не так ли? Плюс это может сказаться на стабильности как файловой системы так и ядра.>Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и,
>как бы это сказать... слишком много на себя берет, что ли.
>По логике -- надо переделать всю VFS, но этот вариант еще
>хуже, чем включение избыточного кода reiser4.
Этот вариант лучше чем включение избыточного кода reiser4. Да более трудоемко но более верно.>Словом -- это действительно тупик, и человеку, который найдет из него приемлемый
>выход, я лично выкачу ящик пива :)
Наиболее верным вариантом будет предоставить новый код VFS с учетом уже включенных FS. А уже затем включать reiser4 с использованием нового VFS. Прогибаться под ядро должна файловая система, а не ядро под файловую систему.
Вы это Мортону говорите, не мне :)
>Вы это Мортону говорите, не мне :)
Это Гансу надо говорить. Мортон правильно его телегу заворачивает.
Не согласен.Обсуждаемый generic-код был написан специально для ext3 и только для ext3. Он нуждается в переделке с первых минут своего существования. Проблема всплыла только сейчас потому, что другие ФС (XFS, JFS, reiserfs) куда тривиальнее reiser4, и их реализация на базе block/page caches не была столь трудоемка, хотя, к примеру, JFS здорово сдала в производительности при переходе с OS/2 на Linux kernel API.
Даже сам Мортон не отрицает (вроде бы) создавшегося положения вещей. Однако передлка VFS и всех основанных на ней файловых систем (а это без малого десяток полнофункциональных ФС) -- задача совершенно неподъемная. С другой стороны, доработка reiser4 под требования Мортона -- это не просто переписывание кода, это отказ от некоторых принципиально нереализуемых на block/page caches возможностей, потеря гибкости и производительности. Или просто введение дополнительных, уже совершенно чудовищных уровней функциональности, которые тем более будут отклонены.
Это не проблема людей (думаю понятно, что и Мортон, и Рейзер по-своему правы ), это проблема VFS и обратной совместимости.
>Обсуждаемый generic-код был написан специально для ext3 и только для ext3. Он
>нуждается в переделке с первых минут своего существования. Проблема всплыла только
>сейчас потому, что другие ФС (XFS, JFS, reiserfs) куда тривиальнее reiser4,
>и их реализация на базе block/page caches не была столь трудоемка,
>хотя, к примеру, JFS здорово сдала в производительности при переходе с
>OS/2 на Linux kernel API.
В таком случае надо меня VFS не так ли ? А не писать свое.>Даже сам Мортон не отрицает (вроде бы) создавшегося положения вещей. Однако передлка
>VFS и всех основанных на ней файловых систем (а это без
>малого десяток полнофункциональных ФС) -- задача совершенно неподъемная. С другой стороны,
>доработка reiser4 под требования Мортона -- это не просто переписывание кода,
>это отказ от некоторых принципиально нереализуемых на block/page caches возможностей, потеря
>гибкости и производительности. Или просто введение дополнительных, уже совершенно чудовищных уровней
>функциональности, которые тем более будут отклонены.
надо менять VFS, а не добавлять файловую систему которая использует свои костыли. С точки зрения ядра это именно костыли. Если каждый так будет делать получим хаос в коде.>Это не проблема людей (думаю понятно, что и Мортон, и Рейзер по-своему
>правы ), это проблема VFS и обратной совместимости.
Тогда объясните мне почему Рейзер вместо доработки VFS добавляет свои костыли ?
>Тогда объясните мне почему Рейзер вместо доработки VFS добавляет свои костыли ?
>Я уже говорил. Проблема VFS не в коде, а в интерфейсах. Переделка интерфейсов повлечет за собой изменение всех основанных на generic-код ФС. Даже Мортон открещивается от выполнения этой задачи, хотя и признает (вроде бы) ее необходимость. Куда уж тут Рейзеру с его пятком программистов!
Хм... XFS в среднем не медлительнее Reiser4. И присутствует в ядре.
Сильно подозреваю, что в оном XFS используются рекомые "устаревшие"
и "много на себя берущие" примитивы. Выводы?
XFS, в среднем, ощутимо _медлительнее_ reiser4.Только не надо требовать бенчмарков -- их по сети полно.
Если интересно, могу скинуть исходники свих тестов.
>XFS, в среднем, ощутимо _медлительнее_ reiser4.
Хорошо давайте теперь переведем reiser4 на generic io и сравним. Иначе не корректное сравнение получается.
Переводите! С меня пиво :)
>XFS, в среднем, ощутимо _медлительнее_ reiser4.
>Только не надо требовать бенчмарков -- их по сети полно.Те бенчмарки, которые видел я, говорят - хрен редьки не слаще.
В каких-то тестах reiser4 чуть шустрее, в каких-то - ровно наоборот.>Если интересно, могу скинуть исходники свих тестов.
Мне, честно говоря, очень лень патчить ядрышко, чтобы добавить
туда reiser4 и прогнать оные тесты. Так что - не интересно :)
Рейзер с такими притензиями - в топку, без разговоров.
Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем более reiser3. Может то, что я видел, устарело? Может кто-нибудь дать линк на свежее сравнилово, где reiser4 рвет всех?
А самому потестить никак? Тоже ядро патчить лень, да проги писать руки не доходят?
Да-а-а, умыл ты меня :-(
Мне и ответить даже нечего... пойду поплачу...
давай-давай :)
>Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем
>более reiser3.Насколько я знаю, reiser4 намного прожорливее, когда речь идёт о процессорном времени. Посмотри на описания аппаратного обеспечения, где тестируются файловые системы.
Полгода назад я тоже искал тесты. Все найденные тесты были проведены на Celeron 500 и ему подобных, потому рейзер и показывал не лучшие результаты (загрузка процессора ~90-95%). При запуске на AthlonXP 3000+ загрузка процессора составляла порядка 15-20%. Для десктопа приемлемо.
Ужасно жду включение Reiser4
сам юзаю пока http://iphitus.loudas.com/beyond.html
Reiser4 жжот полюбому!
>>Reiser4 жжот полюбому!
Подарить огнетушитель и лекарство от ожегов?