форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (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 Новость: http://www.opennet.me/opennews/art.shtml?num=7680

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

Сообщения по теме

[Сортировка по ответам]

	1. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от universite (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"
	Сообщение от пИнгвин on 06-Июн-06, 15:27
	О! Reiser4 наконец. Жду!
	Правка | Высказать мнение | Ответить | 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 (??) 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 (ok) on 06-Июн-06, 19:43
	>По-русски говоря -- они уперлись лбами и уже больше года дале не >движется. Самый простой способ - сделать две ветки ядра :) С reiser4  и без.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх | ^

	9. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от const86 (??) on 06-Июн-06, 19:58
	Её уже год, если не больше, включают...
	Правка | Высказать мнение | Ответить | 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 (??) on 07-Июн-06, 07:31
	>Но нельзя не согласится и с Гансом Рейзером, который указывает, что названные подсистемы >написаны не оптимально, и существенный прирост производительности, демонстрируемый reiser4, был достигнут >в основном благодаря отказу от их использования. Тут вот возникает вопрос не оптимально для reiser4 или все же в общем случае? Если только для reiser4, я бы тоже был против включения такого кода в ядро. Не взирая насколько он хорош это может грозить проблемами после включения кода в ядро.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх | ^

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

	13. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от Terteron on 07-Июн-06, 10:41
	Рейзер с такими притензиями - в топку, без разговоров.
	Правка | Высказать мнение | Ответить | 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 (??) on 07-Июн-06, 11:31
	>Да как сказать... Есть generic-код, использование которого настоятельно рекомендуется при написании файловых >систем. Но если он ограничивает не только свободу мысли разработчика, но >и функциональность будущей ФС? Может в таком случае стоит заняться предложениями по модификации generic-кода VFS ? >Если разобраться, в reiser4 есть части, реализовать которые на основе существующего блочного >кэша действительно практически невозможно -- взять хотя бы транскрэши/экстренный сброс(eflush) и >все, что с ними связано. Мортон предлагает просто выкинуть эти подсистемы >из ФС, но что тогда отанется от reiser4? Но делать это в обход стандартного API ядра не совсем верно не так ли? Плюс это может сказаться на стабильности как файловой системы так и ядра. >Претензии Рейзера и Савельева здесь вполне справедливы -- generic-код действительно устарел, и, >как бы это сказать... слишком много на себя берет, что ли. >По логике -- надо переделать всю VFS, но этот вариант еще >хуже, чем включение избыточного кода reiser4. Этот вариант лучше чем включение избыточного кода reiser4. Да более трудоемко но более верно. >Словом -- это действительно тупик, и человеку, который найдет из него приемлемый >выход, я лично выкачу ящик пива :) Наиболее верным вариантом будет предоставить новый код VFS с учетом уже включенных FS. А уже затем включать reiser4 с использованием нового VFS. Прогибаться под ядро должна файловая система, а не ядро под файловую систему.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх | ^

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

	20. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от DeadMustdie (??) 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ообщить модератору | Наверх | ^

	22. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от sauron (??) 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ообщить модератору | Наверх | ^

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

	24. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от fresco (ok) on 07-Июн-06, 16:12
	>Тогда объясните мне почему Рейзер вместо доработки VFS добавляет свои костыли ? > Я уже говорил. Проблема VFS не в коде, а в интерфейсах. Переделка интерфейсов повлечет за собой изменение всех основанных на generic-код ФС. Даже Мортон открещивается от выполнения этой задачи, хотя и признает (вроде бы) ее необходимость. Куда уж тут Рейзеру с его пятком программистов!
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх | ^

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

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

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

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

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

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

	33. "Linux ядро 2.6.16.20. Планы относительно 2.6.18"
	Сообщение от pv on 18-Июн-06, 22:26
	>Люди, сколько не видел бенчмарков, везде reiser4 уступал и ext3 и тем >более reiser3. Насколько я знаю, reiser4 намного прожорливее, когда речь идёт о процессорном времени. Посмотри на описания аппаратного обеспечения, где тестируются файловые системы. Полгода назад я тоже искал тесты. Все найденные тесты были проведены на Celeron 500 и ему подобных, потому рейзер и показывал не лучшие результаты (загрузка процессора ~90-95%). При запуске на AthlonXP 3000+ загрузка процессора составляла порядка 15-20%. Для десктопа приемлемо.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх | ^

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