The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Linux ядро 2.6.16.20. Планы относительно 2.6.18"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от opennews (ok) on 06-Июн-06, 14:49 
В обновлении 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=7680

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от universite email(ok) on 06-Июн-06, 14:49 
Поистине строительство Вавилонской башни. :(
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от MainFrame on 06-Июн-06, 15:21 
ты сторонник микрокернельного подхода?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от пИнгвин email on 06-Июн-06, 15:27 
О! Reiser4 наконец. Жду!
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от const86 (??) on 06-Июн-06, 19:58 
Её уже год, если не больше, включают...
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco on 06-Июн-06, 16:30 
Я не ошибся -- reiser4 действительно будет включена?!
Действительно хорошая новость!
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco on 06-Июн-06, 16:40 
А, понял.

Включение reiser4 пока только обсуждается. В примечании к этому набору патчей сказано, что эта ФС пока находится на раннем этапе развития и нуждается в развернутом тестировании производительности. Скорее всего -- merging будет отложено, как и раньше.

Не любит ее Мортон, что поделаешь...

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от pavlinux email(??) on 06-Июн-06, 17:22 
> Не любит ее Мортон, что поделаешь...
Мортон, то как раз и с пониманием относится..., а вот Пингвин-Торвальдс как раз наоборот
говорит что reiser4 - "... not a Linux kernel style programming"
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco on 06-Июн-06, 19:36 
Напротив, Торвальдс по поводу reiser4 давно не высказывался. И к стилю программирования претензии давно не выдвигаются -- в ход пошли гораздо более серьезные аргументы. Главные идеолги "невключения" reiser4 -- Мортон и Кокс.

В общих чертах суть их недовольства заключается в том, что reiser4 не только мало использует generic-код, предназначенный для автоматизации рутинной работы, наличиствующей почти во всех ФС (типа generic-read, generic-write, тесно интегрированные со страничным и блочным кэшами), но и своими плагинами вносит в ядро избыточную функциональность, уже реализованную в слое VFS. Где-то они, конечно, правы. Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут в основном благодаря отказу от их использования.

По-русски говоря -- они уперлись лбами и уже больше года дале не движется.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от universite email(ok) on 06-Июн-06, 19:43 
>По-русски говоря -- они уперлись лбами и уже больше года дале не
>движется.

Самый простой способ - сделать две ветки ядра :)
С reiser4  и без.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от pavlinux (ok) on 06-Июн-06, 22:50 
> сделать две ветки ядра

Ага, Щщщасс, ... скорее пингвины станут перелётными птицами...  

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 07:31 
>Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы
>написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут
>в основном благодаря отказу от их использования.
Тут вот возникает вопрос не оптимально для reiser4 или все же в общем случае? Если только для reiser4, я бы тоже был против включения такого кода в ядро. Не взирая насколько он хорош это может грозить проблемами после включения кода в ядро.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от Zlobec email on 07-Июн-06, 09:33 
Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не оптимален а второй оптимален но не стандартен не есть хорошо для ядра в котором и так полный бардак.

Вобщем Рейзеру надо не выпендриваться и выложить код под BSD ))

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

16. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 11:32 
>Наличие двух вариантов делать одно дейстиве один из которых стандартный, но не
>оптимален а второй оптимален но не стандартен не есть хорошо для
>ядра в котором и так полный бардак.
Вот вот. Потом где гарантии, что оптимальное для reiser4 будет оптимально для остальных файловых систем?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

14. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco on 07-Июн-06, 11:08 
Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых систем. Но если он ограничивает не только свободу мысли разработчика, но и функциональность будущей ФС?

Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы из ФС, но что тогда отанется от reiser4?

Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и, как бы это сказать... слишком много на себя берет, что ли. По логике -- надо переделать всю VFS, но этот вариант еще хуже, чем включение избыточного кода reiser4.

Словом -- это действительно тупик, и человеку, который найдет из него приемлемый выход, я лично выкачу ящик пива :)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

15. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 11:31 
>Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых
>систем. Но если он ограничивает не только свободу мысли разработчика, но
>и функциональность будущей ФС?

Может в таком случае стоит заняться предложениями по модификации generic-кода VFS ?

>Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного
>кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и
>все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы
>из ФС, но что тогда отанется от reiser4?
Но делать это в обход стандартного API ядра не совсем верно не так ли? Плюс это может сказаться на стабильности как файловой системы так и ядра.

>Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и,
>как бы это сказать... слишком много на себя берет, что ли.
>По логике -- надо переделать всю VFS, но этот вариант еще
>хуже, чем включение избыточного кода reiser4.
Этот вариант лучше чем включение избыточного кода reiser4. Да более трудоемко но более верно.

>Словом -- это действительно тупик, и человеку, который найдет из него приемлемый
>выход, я лично выкачу ящик пива :)
Наиболее верным вариантом будет предоставить новый код VFS с учетом уже включенных FS. А уже затем включать reiser4 с использованием нового VFS. Прогибаться под ядро должна файловая система, а не ядро под файловую систему.


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

17. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco on 07-Июн-06, 12:40 
Вы это Мортону говорите, не мне  :)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

18. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 12:44 
>Вы это Мортону говорите, не мне  :)
Это Гансу надо говорить. Мортон правильно его телегу заворачивает.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

19. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco (ok) on 07-Июн-06, 13:14 
Не согласен.

Обсуждаемый generic-код был написан специально для ext3 и только для ext3. Он нуждается в переделке с первых минут своего существования. Проблема всплыла только сейчас потому, что другие ФС (XFS, JFS, reiserfs) куда тривиальнее reiser4, и их реализация на базе block/page caches не была столь трудоемка, хотя, к примеру, JFS здорово сдала в производительности при переходе с OS/2 на Linux kernel API.

Даже сам Мортон не отрицает (вроде бы) создавшегося положения вещей. Однако передлка VFS и всех основанных на ней файловых систем (а это без малого десяток полнофункциональных ФС) -- задача совершенно неподъемная. С другой стороны, доработка reiser4 под требования Мортона -- это не просто переписывание кода, это отказ от некоторых принципиально нереализуемых на block/page caches возможностей, потеря гибкости и производительности. Или просто введение дополнительных, уже совершенно чудовищных уровней функциональности, которые тем более будут отклонены.

Это не проблема людей (думаю понятно, что и Мортон, и Рейзер по-своему правы ), это проблема VFS и обратной совместимости.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

22. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 14:39 
>Обсуждаемый 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 добавляет свои костыли ?


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

24. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco (ok) on 07-Июн-06, 16:12 
>Тогда объясните мне почему Рейзер вместо доработки VFS добавляет свои костыли ?
>

Я уже говорил. Проблема VFS не в коде, а в интерфейсах. Переделка интерфейсов повлечет за собой изменение всех основанных на generic-код ФС. Даже Мортон открещивается от выполнения этой задачи, хотя и признает (вроде бы) ее необходимость. Куда уж тут Рейзеру с его пятком программистов!


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

20. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от DeadMustdie email(??) on 07-Июн-06, 13:40 
Хм... XFS в среднем не медлительнее Reiser4. И присутствует в ядре.
Сильно подозреваю, что в оном XFS используются рекомые "устаревшие"
и "много на себя берущие" примитивы. Выводы?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

21. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco (ok) on 07-Июн-06, 13:58 
XFS, в среднем, ощутимо _медлительнее_ reiser4.

Только не надо требовать бенчмарков -- их по сети полно.

Если интересно, могу скинуть исходники свих тестов.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

23. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от sauron email(??) on 07-Июн-06, 14:42 
>XFS, в среднем, ощутимо _медлительнее_ reiser4.
Хорошо давайте теперь переведем reiser4 на generic io и сравним. Иначе не корректное сравнение получается.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

27. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от fresco (??) on 08-Июн-06, 08:25 
Переводите! С меня пиво :)
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

26. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от DeadMustdie email(??) on 07-Июн-06, 20:05 
>XFS, в среднем, ощутимо _медлительнее_ reiser4.
>Только не надо требовать бенчмарков -- их по сети полно.

Те бенчмарки, которые видел я, говорят - хрен редьки не слаще.
В каких-то тестах reiser4 чуть шустрее, в каких-то - ровно наоборот.

>Если интересно, могу скинуть исходники свих тестов.

Мне, честно говоря, очень лень патчить ядрышко, чтобы добавить
туда reiser4 и прогнать оные тесты. Так что - не интересно :)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

13. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от Terteron on 07-Июн-06, 10:41 
Рейзер с такими притензиями - в топку, без разговоров.
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

25. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от funny_falcon on 07-Июн-06, 19:28 
Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем более reiser3. Может то, что я видел, устарело? Может кто-нибудь дать линк на свежее сравнилово, где reiser4 рвет всех?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

28. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от xu on 08-Июн-06, 08:26 
А самому потестить никак? Тоже ядро патчить лень, да проги писать руки не доходят?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

29. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от funny_falcon on 08-Июн-06, 16:49 
Да-а-а, умыл ты меня :-(
Мне и ответить даже нечего... пойду поплачу...
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

31. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от xu on 09-Июн-06, 11:33 
давай-давай  :)
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

33. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от pv email on 18-Июн-06, 22:26 
>Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем
>более reiser3.

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

Полгода назад я тоже искал тесты. Все найденные тесты были проведены на Celeron 500 и ему подобных, потому рейзер и показывал не лучшие результаты (загрузка процессора ~90-95%). При запуске на AthlonXP 3000+ загрузка процессора составляла порядка 15-20%. Для десктопа приемлемо.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

30. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от c400 on 09-Июн-06, 03:15 
Ужасно жду включение Reiser4
сам юзаю пока http://iphitus.loudas.com/beyond.html
Reiser4 жжот полюбому!
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

32. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"  
Сообщение от Radeon email on 10-Июн-06, 15:14 
>>Reiser4 жжот полюбому!
Подарить огнетушитель и лекарство от ожегов?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру