Грег Кроа-Хартман (Greg Kroah-Hartman) представил (http://lkml.org/lkml/2013/7/1/389) очередной список патчей, планируемых для включения в состав экспериментального раздела "staging" ядра Linux 3.11. Наиболее важным новшеством является интеграция в ядро клиента кластерной файловой системы Lustre (http://wiki.lustre.org/index.php/Main_Page), используемой в большинстве кластеров, входящих в список самых мощных суперкомпьютеров мира. Клиентская часть Lustre работает (http://ru.wikipedia.org/wiki/Lustre_%28%D1%81... вкупе с серверами для хранения данных и обслуживания метаданных, предоставляя средства для обращения клиентов к хранимым в распределённой ФС данным (основанный на ext4 бэкенд ldiskfs для организации работы сервера хранения данных в ядро не включен).
URL: http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/00398....
Новость: http://www.opennet.ru/opennews/art.shtml?num=37328
С лицензиями утрясли?
> С лицензиями утрясли?Что с ними (с ней?) не так? Оракл опять опозорился?
читать умеем? причем там Oracle? хотя чукча похоже только писатель..
> читать умеем? причем там Oracle? хотя чукча похоже только писатель..Когда кто-то позорится с лицензией, первая мысль у народа - "опять этот оракакел".
вторая строчка в ссылках к новости
>>>OpenNews: Компания Xyratex выкупила у Oracle распределённую ФС Lustre
>>>читать не разучились?
> читать умеем? причем там Oracle? хотя чукча похоже только писатель..Оракл "участвовал в судьбе". С лицензиями у него всё интересно. Да, вывод неверный, не уследил за и новость не читал. Куда уж мне до табя-то. </пойман не вор>
>> читать умеем? причем там Oracle? хотя чукча похоже только писатель..
> Оракл "участвовал в судьбе". С лицензиями у него всё интересно. Да, вывод
> неверный, не уследил за и новость не читал. Куда уж мне
> до табя-то. </пойман не вор>участвовал? когда? ех.. хоть бы ознакомились с тем что было и как случилось..
>>> читать умеем? причем там Oracle? хотя чукча похоже только писатель..
>> Оракл "участвовал в судьбе". С лицензиями у него всё интересно. Да, вывод
> участвовал? когда? ех.. хоть бы ознакомились с тем что было и как случилось..Как там... "читать умеем?" ?..
"""вице-президент Oracle, [...] в своем блоге [...] заверил клиентов, что судьба Lustre, после поглощения Sun Microsystems, вне опасности и Oracle планирует продолжить инвестиции
"""Компания Xyratex выкупила у Oracle [...]
к тому моменту когда это в блоге появилось - ключевых разработчиков Lustre в Oracle не было. И очень скоро после этого ушли остальные.. Вы бы еще данные за прошлый век вытянули..
Джва года ждал!
> Джва года ждал!пушистый зверек пришел стараниями EMC. о многоплатформенности можно забыть, началась фраментация дерева и остальной головняк. Whamcloud & EMC не имеют четкого плана что же теперь делать когда клиента запихнули в ядро - только кричат что это круто и проблемы со сборкой пропадут (что весьма не факт).
Теперь смотрим на головняк - ядра RHEL поддерживают порядка 6 лет. За это время успевает выйти (в нормальном режиме) порядка 3х major release. Изначально декларировалось что поддерживается только +/- major release в режиме совместимости. И того - или надо удерживать совместимость. Или получаем кучу не поддерживаемых клиентов - которые не понятно кому нужны. _ТОЧКА_.
в качестве бэкграунда - стараниями EMC убит слой переностимости между разными платформами. Если раньше существовал Fuse клиент на macos/freebsd и был native клиент под win32/macos - то теперь об этом можно забыть.
Как вам такая перспектива?
> убит слой переностимости между разными платформами.Как ты себе представляешь перенос кластера, и вообще какой тайный смысл в разнородности?
>> убит слой переностимости между разными платформами.
> Как ты себе представляешь перенос кластера, и вообще какой тайный смысл в
> разнородности?Поверь представляю и даже поддерживаю это.
BP (british petroleum) & Total - используют люстру в mixed env - где люстра предоставляет просто большой сетевой сторадж (аналог HP SFS серии).
Для клиентов под MacOS & Windows доступны CIFS/NFS шары - ограничения CIFS / NFS думаю понятны?
А когда-то давно был даже сделан MacOS client (в дереве до сих пор валяются следы), и freebsd/macos fuse клиент - теперь есть шанс что это все похерят - стараниями EMC и Андреаса Дилгера...
> А когда-то давно был даже сделан MacOS client (в дереве до сих
> пор валяются следы), и freebsd/macos fuse клиент - теперь есть шанс
> что это все похерят - стараниями EMC и Андреаса Дилгера...И это хорошо. Недопиленный и ненужный крап идет лесом.
>> А когда-то давно был даже сделан MacOS client (в дереве до сих
>> пор валяются следы), и freebsd/macos fuse клиент - теперь есть шанс
>> что это все похерят - стараниями EMC и Андреаса Дилгера...
> И это хорошо. Недопиленный и ненужный крап идет лесом.кто сказал что не допиленый? и кто сказал что крап?
вот фирмы Total & BP (как впрочем и все остальные клиенты с HP SFS) считают иначе. И только Аноним назвал это крапом..
Подозреваю, что эти фирмы ничего не сичтают, просто у них по историческим причинам вырос зоопарк и его трогать лишний раз себе дороже. Таких случаев вагон и маленькая тележка. При возможности от гетерогенности всегда выгодно избавляться.
Ты поработай на этом рынке - а потом "подозревай".
> Ты поработай на этом рынке - а потом "подозревай".Так ты на рынке работаешь? Что ж сразу не сказал?
Что продаёшь: китайские пуховики или шаверму?
> теперь есть шанс что это все похерятНе вижу связи. Наоборот, логичнее предположить, что реализация в ядре Linux будет эталоном. на которую будут ориентироваться все остальные.
логично понять что существует 10 дистрибутивов - реализация в каком из них будет эталоном?
С учетом того что сервер развивается где-то в другом месте.
Мне почему-то кажется, что авторы дистров не будут подпиливать поддержку люстры настолько глубоко, чтобы вариант в их ядре перестал быть совместимым с ванильным.
еще раз. Авторы дистра блокируют весию на момент заморозки. За это время разработка идет паралельно - но в эти дистрибутивные ядра не бэкпортятся изменения. В результате через 2-3 года - версия клиента из "замороженного" ядра - становится не совместимой с актуальной версией сервера, кроме того эти версии не включают в себя все фиксы которые были за это сделаны. Вот она причина не совместимости.Теперь понятно ?
> логично понять что существует 10 дистрибутивов - реализация в каком из них будет эталоном?В майнлайн кернеле - текущая версия эталона :).Кто-то слоупочит, кто-то нет. Вероятно те кто слоупочит (редхат с 2.6.32 и прочая) будут яростно бэкпортить. Чем они любят заниматься.
>> логично понять что существует 10 дистрибутивов - реализация в каком из них будет эталоном?
> В майнлайн кернеле - текущая версия эталона :).Кто-то слоупочит, кто-то нет. Вероятно
> те кто слоупочит (редхат с 2.6.32 и прочая) будут яростно бэкпортить.
> Чем они любят заниматься.Одним из них будет фирмочка Cray - благодаря которому Lustre появилась в top500/top10.
Которая заинтересована в SLES only, а никак не vanila kernel.
Как вы думаете что будет выгоднее этой фирме?
Ну и ладушки, будет меньше зоопарка. Опять же, лишний гвоздь в гроб BSD - тоже дело хорошее, чего корм проприетарщикам плодить.
> Ну и ладушки, будет меньше зоопарка. Опять же, лишний гвоздь в гроб
> BSD - тоже дело хорошее, чего корм проприетарщикам плодить.надо в рамку. А вам RTFM что такое фрагментация платформы.
PS. клиентам надо под дистрибутивные ядра - а что там в vanila их интересует мало.
> надо в рамку. А вам RTFM что такое фрагментация платформы.Вот теперь и не будет фрагментации. За что боролись - на то и напоролись?
> PS. клиентам надо под дистрибутивные ядра - а что там в
> vanila их интересует мало.А дистрибутивы не перепиливают код ваниллы лишний раз без хорошей причины. Оно им надо - лишнюю работу делать?
>> надо в рамку. А вам RTFM что такое фрагментация платформы.
> Вот теперь и не будет фрагментации. За что боролись - на то
> и напоролись?фрагментация - это когда куча не совместимых вещей. У люстры всегда был один дистрибутив - одна версия и тп. Не было фрагментации - сейчас каждый дистрибутив будет иметь какую-то свою версию люстры - зависящую от того в какой момент дистрибутив взял ядро из mainstream.
так понятно?>> PS. клиентам надо под дистрибутивные ядра - а что там в
>> vanila их интересует мало.
> А дистрибутивы не перепиливают код ваниллы лишний раз без хорошей причины. Оно
> им надо - лишнюю работу делать?еще раз. Ubuntu - фиксирует 3.8 ядро, RHEL 2.6.32 - версии клиентов которые могли бы там оказаться.
2.4 (с непонятно каким состоянием) и 2.0 (уже не поддерживаемый).при этом 2.4 сервер с 2.0 клиентом уже не работает - но многие крупные клиенты сидят на RHEL6 и слазить не будут. Так понятно ?
> сейчас каждый дистрибутив будет иметь какую-то свою версию люстры - зависящую
> от того в какой момент дистрибутив взял ядро из mainstream.
> так понятно?Как самый максимум - появится стимул не разводить зоопарк и использовать окружения с одним и тем же дистром. Заодно еще и затраты на администрирование меньше будут. А уж сам с собой дистр будет совместим.
Могу предположить что референсом будет майнлайн а люьители ынтырпрайзного стабилизца будут яростно бэкпортить свежие версии этого самого в свои древние 2.6.32, по крайней мере они всегда это делали :)
> 2.4 (с непонятно каким состоянием) и 2.0 (уже не поддерживаемый).
Ну значит кто-то будет юзать только редхат а кто-то только убунту. Если кому по крупному что-то не понравится - решения наверняка найдут. Думается что редхат какой-нибудь вполне может бэкпортировать свежак в свои 2.6.чтототам окаменевшие. Они всегда это делают.
> многие крупные клиенты сидят на RHEL6 и слазить не будут. Так понятно ?
Ну и будут юзать свой рхел6 в каждой дырке, как наиболее логичное решение. Или там убунту. Или что им там удобнее. А зачем им вообще зоопарк разводить? А если кого напряжет по крупному - решения найдут.
То есть ситуация что Ubuntu и RHEL не совместимы между собой уже воспринимается нормальной ?
> То есть ситуация что Ubuntu и RHEL не совместимы между собой уже
> воспринимается нормальной ?Это разные ОС, чо. Если кто-то когда-то поверил воплям фанатиков, что Linux - это круто, потому что одно ядро на всех - можно этому человеку только посочувствовать.
>[оверквотинг удален]
>> Как ты себе представляешь перенос кластера, и вообще какой тайный смысл в
>> разнородности?
> Поверь представляю и даже поддерживаю это.
> BP (british petroleum) & Total - используют люстру в mixed env -
> где люстра предоставляет просто большой сетевой сторадж (аналог HP SFS серии).
> Для клиентов под MacOS & Windows доступны CIFS/NFS шары - ограничения CIFS
> / NFS думаю понятны?
> А когда-то давно был даже сделан MacOS client (в дереве до сих
> пор валяются следы), и freebsd/macos fuse клиент - теперь есть шанс
> что это все похерят - стараниями EMC и Андреаса Дилгера...пусть BP и Total достоют свои большие и толстые кошельки и начинают спонсировать разработку того, что им нужно.
к.о. подсказывает, что если бы им действительно этот storage был важен, то всё было бы чики-пики, а так нового подрядчика наймут и ок.
p.s. новый подрядчик от старого обслуживающего персонала избавится
>[оверквотинг удален]
>> где люстра предоставляет просто большой сетевой сторадж (аналог HP SFS серии).
>> Для клиентов под MacOS & Windows доступны CIFS/NFS шары - ограничения CIFS
>> / NFS думаю понятны?
>> А когда-то давно был даже сделан MacOS client (в дереве до сих
>> пор валяются следы), и freebsd/macos fuse клиент - теперь есть шанс
>> что это все похерят - стараниями EMC и Андреаса Дилгера...
> пусть BP и Total достоют свои большие и толстые кошельки и начинают
> спонсировать разработку того, что им нужно.
> к.о. подсказывает, что если бы им действительно этот storage был важен, то
> всё было бы чики-пики, а так нового подрядчика наймут и ок.Если бы Intel и EMC не делали то что хотели - и то что им кажется важным, было бы нормально.
А это.. Intel заигрался в постоянную разработку и больше не будет выпускать открытых стабильных версий.
> Если бы Intel и EMC не делали то что хотели -С дубу рухнули? Не, блин, вот сейчас Intel и EMC побегут делать не то что надо им, а то что надо вам. Губозакатывательную машинку купите.
> и то что им кажется важным, было бы нормально.
Нормально кому? Явно не Intel и EMC, да? А чего это они должны свои корпоративные ресурсы тратить на ваше удобство, собственно? :)
> А это.. Intel заигрался в постоянную разработку и больше не будет выпускать
> открытых стабильных версий.Это такая современная форма "зелен виноград"? :)
>> Если бы Intel и EMC не делали то что хотели -
> С дубу рухнули? Не, блин, вот сейчас Intel и EMC побегут делать
> не то что надо им, а то что надо вам. Губозакатывательную
> машинку купите.Пара писем и пойдут делать. Права на Lustre им не принадлежат. Как и управляется это OpenSFS foundation - а Intel это наемный работник. Историю вопроса надо знать.
>> и то что им кажется важным, было бы нормально.
> Нормально кому? Явно не Intel и EMC, да? А чего это они
> должны свои корпоративные ресурсы тратить на ваше удобство, собственно? :)Потому что они наемные работники. и точка. Они получают деньги за свою работу и каждый год им утверждают контракт. Следующий год могут не утвердить.
Сдается мне они вышли за свою компетенцию.
>> А это.. Intel заигрался в постоянную разработку и больше не будет выпускать
>> открытых стабильных версий.
> Это такая современная форма "зелен виноград"? :)Это не знание вам предметной сферы.
Воте коли действительно будет так, как ты говоришь, то я признаю что был неправ. Пока минус тебе. За ник.
> BP (british petroleum) & Total - используют люстру в mixed env -Приветы Песковой Дарье передавай :)
> Как ты себе представляешь перенос кластера, и вообще какой тайный смысл в
> разнородности?Он все еще никак не может отойти от звездной болезни и смириться с мыслью что всякий недоразвитый и проблемный софт типа *bsd корпорации более вообще не интересует в массе своей.
Если посмотреть на перечисленные - а что они из себя представляют? Макось - опять же, там эппл верховодит а остальные не велкам, карманный проектик такой. Поэтому остальным корпорасам они до лампочки. Это же не у них система, а у эппла. Корпорасы это в состоянии понять - чуть бизнес интересы не так и им там кислород перекроют в 2 счета. С виндой - аналогично, но эппл заменяется на мс. С бсд каши не сваришь - управление проектом у граждан шибанутое, по поводу чего бизнесу они в массе своей бесполезны и неинтересны. Такая фигня.
Ну вот наверное эффективные манагеры в EMC и решили что нафиг поддерживать слой совместимости от которого отдачи ноль целых, хрен десятых. Они ж не будут развивать фетиш линуксрипа только на том основании что ему это нравится.
> Ну вот наверное эффективные манагеры в EMC и решили что нафиг поддерживать
> слой совместимости от которого отдачи ноль целых, хрен десятых. Они ж
> не будут развивать фетиш линуксрипа только на том основании что ему
> это нравится.EMC к Lustre никаким боком не относятся. Вы бы не бредили а интересовались предметной областью..
Развития Lustre контролируется OpenSFS - Intel/Xyratex.
> Как ты себе представляешь перенос кластераК.О. подсказывает - через подключение новых узлов и вывод из эксплуатации устаревших, показывающих плохую диагностику и тому подобных.
теория заговора какая-то прямо:)
довольно часто вижу в коммит-логе фревом "Sponsored by:EMC / Isilon Storage Division"
никак пацанва хочет иметь несколько ОС/дистрибутивов под боком которые друг с дружкой не дружат!
> никак пацанва хочет иметь несколько ОС/дистрибутивов под бокомТебе как представителю "пацанвы" виднее :)
Ваш переход на личность не отменяет факт.
> Если раньше существовал Fuse клиент на macos/freebsd и был native клиент
> под win32/macos - то теперь об этом можно забыть.
> Как вам такая перспектива?Мне нравится. Ты так шестерил перед акулами бизнеса, что вполне заслужил нарваться наконец на то что они из себя по факту представляют в самой жесткой и неприятной форме. Ты это заслужил, чувак.
>> Если раньше существовал Fuse клиент на macos/freebsd и был native клиент
>> под win32/macos - то теперь об этом можно забыть.
>> Как вам такая перспектива?
> Мне нравится. Ты так шестерил перед акулами бизнеса, что вполне заслужил нарваться
> наконец на то что они из себя по факту представляют в
> самой жесткой и неприятной форме. Ты это заслужил, чувак.Нравится убивать открытые проекты? Я без работы не останусь и ничего не пострадает из моих инетерсов.
А вот пострадают другие люди - вот это плохо.Хотя линуксоиды привыкли что они пуп мира - и думать о других им не привыкать.
А ты уже убил своих детей по заветам столмана ?
> Нравится убивать открытые проекты?От включения в линевое ядро еще никто не умирал. А, погодите, я догадаюсь: вы настолько эпический ламак что путаете открытость и кроссплаформенность?
> Я без работы не останусь и ничего не пострадает из моих инетерсов.
Рад за вас и все такое. Тогда мне не слишком понятно, почему вы вашим батхертом весь форум забрызгали.
> А вот пострадают другие люди - вот это плохо.
Всякие эпплы/майкрософты/санко-ораклы всегда думали только о том чтобы набить свой карман, а что случится с остальными им было чихать. У них довольно закрытые экоситемы в которых посторонних вообще не ждут. Что мешает многим другим деньги зарабатывать. По этому поводу этих мне не жалко. Акулы которые просекли фишку подгадили акулам которые не просекли фишку. Какая досада. </sarcasm>
Бздшники всегда быковали на пингвины, сколько я себя помню. Если вы с вашим ником надеетесь на сочувствие и понимание - боюсь, это немного фэйловато.
> Хотя линуксоиды привыкли что они пуп мира - и думать о других им не привыкать.
Заботиться о таких как вы - себя не уважать. Сами о себе с таким ником как-нибудь позаботитесь.
> А ты уже убил своих детей по заветам столмана ?
Он нигде не призывал детей убивать, btw.
Поддержка всяких устаревших платформ с 2% пользователей никому не нужна, например. А кому нужна, пусть платят. Виндюзня и и макосня должна страдать.
Еще один который не понял что сделали.. Лана там MacOS, Windows - хотя это в вас говорит просто зависть и нишебродство. В Американских лабораториях очень много Window, MacOS - так что этим ходом у люстры отрезали очень большой кусок рынка - чем другие воспользуются. Лана - это лирика..Есть и другой момент.
Сейчас есть пусть 10 основных дистрибутивов.
Каждый замораживает ядро в свое время - как кому захочется, в результате версии люстра клиентов у всех разные. С момента заморозки версии клиентов не меняется. Сервер поддерживает -1 версию клиента. Клиент всегда +/- 1 версию сервера.. В результате в том же RHEL, Ubuntu и тп - в ядре окажется настолько старый клиент что для него не найдется сервера.
При этом клиенты не будут развиваться в плане поддержки старых ядер. И что будете делать через 2 года после выпуска нового дистрибутива шапкой?
Останетесь с разбитым корытом?Ну пожалуйста - обслуживайте дальше желания EMC и прогибайтесь под ним, считая что сделали зло MacOS, Windows и BSD системам.
Не понял плача. Кто мешает синхронизировать переезды на новые версии клиента и сервера (если это вообще надо делать, в чем я совсем не уверен в данном случае)?
> хотя это в вас говорит просто зависть и нишебродство.Как по мне, вернуть этим ушлым комерсам их подходы - более чем честно. Они всегда относились к окружающим как к второму сорту и/или бесплатной кормушке. Пусть сами теперь побудут вторым сортом и насладятся всеми прелестями.
> люстры отрезали очень большой кусок рынка - чем другие воспользуются.
Заблобизированные системы в кастомных применениях типа лабораторий - хорошая заявка на головняк, заморочки с лицензированием и прочий нафиг не упавший крап. Так что я думаю что рыночные доли может и изменятся, но иначе. ИМХО, чихали в редмонде и купертино на лаборатории какие-то там и их нужды.
> - в ядре окажется настолько старый клиент что для него не найдется сервера.
...кроме такой же операционки на сервере, что является наиболее логичным решением с точки зрения минимизации зоопарка ;).
> что будете делать через 2 года после выпуска нового дистрибутива шапкой?
То же что и обычно - обновят дистры и на клиентах и на серверах. И все.
> Останетесь с разбитым корытом?Все будет чики-пуки. Просто смигрируют и клиента и сервера одновременно.
> что сделали зло MacOS, Windows и BSD системам.
Зло не зло а небольшое конкурентное преимущество - оттяпали.
Давай, рассказывай нам, как ты несчастную redhat жалеешь. Есть Ubuntu на клиентах и RedHat на серверах. Если RedHat не поддерживает работу клиента, то кому он нужен как сервер? Значит сносим RedHat и ставим Ubuntu сервер. Вот только в redhat не такие как ты сидят, они это не хуже меня понимают и проблему решат. Так что и проблемы такой не будет.
когда покажите у убунтны EAL4 сертификацию - тогда поговорим - о "сносим redhat и ставим убунту".
поэтому сносим redhat не будет в принципе.. ты слишком заигрался в админа конторы рога и копыта, у правительственных лабораторий связаных с ядерным департаментом США - чуть чуть другие требования...
> Как вам такая перспектива?Пусть вкладываются или сидят на NFS-реэкспорте, нормально.
>> Как вам такая перспектива?
> Пусть вкладываются или сидят на NFS-реэкспорте, нормально.Шигорин - ты бы хоть молчал. я все таки думал что ты поймешь что фрагментация это плохо.
> поймешь что фрагментация это плохо.Как раз фрагментации теперь и не будет :). Будет единственно правильная люстра из ядра линя. А кому не нравится - в праве не пользоваться линухом и пойти нафиг. "У вас есть выбор".
>> поймешь что фрагментация это плохо.
> Как раз фрагментации теперь и не будет :). Будет единственно правильная люстра
> из ядра линя. А кому не нравится - в праве не
> пользоваться линухом и пойти нафиг. "У вас есть выбор".Не знаю зачем стерли ответ. Но люстра не желец без лабораторий США, а им не интересны всякие vanila ядра.
Совсем не интересны. Cray интересна люстра под SLES, HP под RHEL, и есть только Bull который иногда использует vanila но только для тестов. Но где тот Bull в списке top10 ?
Сейчас же для Cray/HP будет отдельный геморой - связаный с тем что люстру которая будет в ядре с дистрибутивом - надо откатить, а новую засунуть.
Так что - единственно правильной будет та люстра - которую будет использовать крей и крупные клиенты, а все остальное или послужит причиной форка и создания не совместимой версии - причем той что в ядре прийдется поменять имя. Или просто Cray/HP слиняют на другую FS, что послужит исчезновению Lustre из top10/100/500.
ну это уже кое что, а то 3.10 как-то не вставило )
Да ладно тебе, с семафорами они там в 3.10 неплохо подкрутили, даже pg_bench заметное улучшение показал.
> pg_bench заметное улучшение показал.Ну да, всего-то на 100% :)
tickless, bcache, crc32 для xfs, VLAN stacking, ipc-scalability, CLOCK_TAI, Tail loss probe... мало?Ты в это будешь втыкать лет 5, чтоб понять что это такое!
VLAN stacking это q-in-q так обозвали?
tickless все делают с времен 2.6.32... конца не видно.. только глюки лезут..
bcache - этакий закос под ZFS cache.. коментарий разрабочика - при wb режиме питание не должно пропадать иначе диск становится неживым, попутно ломает логику jbd2 журнала (да и много чего другого что надется на синхронную запись на диск). без wb режима под нагрузкой не интересен - более интересен рейд с памятью и батарейкой.приколы остального продолжать ?
> bcache - этакий закос под ZFS cache.. коментарий разрабочика - при wb
> режиме питание не должно пропадать иначе диск становится неживым,Так сие для стратегии кэширования WB - обычное дело вроде.
> приколы остального продолжать ?
Да зачем? Будем считать что линукс крап, пользуйся чем-нибудь другим - так тебе и надо будет :).
>> bcache - этакий закос под ZFS cache.. коментарий разрабочика - при wb
>> режиме питание не должно пропадать иначе диск становится неживым,
> Так сие для стратегии кэширования WB - обычное дело вроде.да ну? рейды с батарейкой живут в WB режиме.
> да ну? рейды с батарейкой живут в WB режиме.Так потому и с батарейкой, бэть, что без нее - трындец полный.
А поскольку тут логика работы немного вылезает за пределы того что может тyповатый контроллер - придется батарейку поставить на всю систему, угу. Для предотвращения ровно того же самого дестроя по похожему поводу.
А есть какие-то лимиты на размер ядра? Новые фичи это хорошо, но ведь в один прекрасный день обнаружится, что ядро стало громадным, а это не есть хорошо. Или, может, из ядра выпиливают всякое старье? Об этом тоже интересно было бы почитать.
http://www.phoronix.com/scan.php?page=news_item&px=MTAxNDg
> http://www.phoronix.com/scan.php?page=news_item&px=MTAxNDgТак это размер тарбола. Пусть хоть гиг будет - кому до этого какое дело?
Подсказка: компилировать всё не надо.
Подсказка2: Модули.
Подсказка3: удаление поддержки 80386
> Подсказка3: удаление поддержки 80386Скоро еще и cgroups удалят :)
> Скоро еще и cgroups удалят :)Пруф? А то что-то их пока вместо удаления допиливают там и тут. Хотя если они сделают что-то лучше и удалят - ну окей, нехай будет next-gen замена. Правда загвоздка в том что я ее пока не знаю. Я чего-то упустил? :)
<mitrofanof style> Развитие же! </mitrofanof style>
> <mitrofanof style> Развитие же! </mitrofanof style>У митрофанова лучше получается. А это так, дешевая китайская подделка. Фи.
>>необходимостью поддерживать ядра начиная с 2.6.32
> Наверное, это кому-нибудь нужно? Или ты предлагаешь _им_ лавочку прикрыть?я ничего не предлагаю - я лишь описываю _СВОЙ_ геморой.
>> hint. переход с 2.6.20 на 2.6.25 обошелся люстре порядка 450кб патча.
> Ты даже не представляешь, во сколько бегомайт патча обошёлся Linux-у "переход с
> 2.6.20 на 2.6.25"!Ты даже не знаешь о чем речь - а пытаешся свое мнение иметь.. к примеру расскажи чем отличается кардинально ->nopage() и ->fault() API для обработки page fault в ядре?
> я ничего не предлагаю - я лишь описываю _СВОЙ_ геморой.Я не понял при чем тут вы. Мне было вообще про cgroups интересно. А ваш геморрой - наверное вообще последнее что меня интересует.
> Ты даже не знаешь о чем речь - а пытаешся свое мнение
А, кажется я понимаю. Вы настолько ушиблись что даже в тред ответить нормально не можете.
> Кроме блобмейкеров есть стопка проектов который opensource и даже GPL но развиваются
> вне ядра. Пример Lustre.Судя по текущей новости это частично пофиксили уже и проблема как минимум частично отпадет :)
> сколько там приходится делать изменений в связи с постоянной сменой
> API и необходимостью поддерживать ядра начиная с 2.6.32 - можно посмотреть в гите."У тебя есть выбор - ты можешь пойти на...й и не пользоваться линуксом, если тебе что-то не нравится". Да, я кое-чему таки научился у твоих проприетарных патронов :).
> hint. переход с 2.6.20 на 2.6.25 обошелся люстре порядка 450кб патча.
Теперь видимо им попроще будет в свете сабжа.
> архитектура приложения это знакомо? не.. не слышал..
Обана, какой эпический фэйл. Ты настолько гонщик, что в процессе летнего гона операционку от приложения не отличаешь? :)
Собственно, а какая у монолитного кернела ОС архитектура? Да в общем то его собачье дело как оно там внутри себя запросы программ обслужит. Поэтому и лепят как получится и как удобно. Даже работает. Монолит является относительно лобовой реализацией обслуживалки запросов. Архитектура по принципу "так проще всего сделать было".
Со временем в лине оформились некие подсистемы и границы между ними и прочая. Так как было удобно разработчикам которые за все это отвечало. Их судя по всему все устраивает, иначе это было бы как-то иначе. А остальных это вообще @#$ть не должно ибо внутренняя кухня ядра.
>> Кроме блобмейкеров есть стопка проектов который opensource и даже GPL но развиваются
>> вне ядра. Пример Lustre.
> Судя по текущей новости это частично пофиксили уже и проблема как минимум
> частично отпадет :)Появятся совсем другие и сильно сложнее.
>> сколько там приходится делать изменений в связи с постоянной сменой
>> API и необходимостью поддерживать ядра начиная с 2.6.32 - можно посмотреть в гите.
> "У тебя есть выбор - ты можешь пойти на...й и не пользоваться
> линуксом, если тебе что-то не нравится". Да, я кое-чему таки научился
> у твоих проприетарных патронов :).Да - материться у тебя получается. А строить логические цепочки - не очень.
>> hint. переход с 2.6.20 на 2.6.25 обошелся люстре порядка 450кб патча.
> Теперь видимо им попроще будет в свете сабжа.Им это кому? Этот патч делал я. Только теперь прийдется делать обратный - для поддержки старых ядер (из состава RHEL) в новых клиентах.
>> архитектура приложения это знакомо? не.. не слышал..
> Обана, какой эпический фэйл. Ты настолько гонщик, что в процессе летнего гона
> операционку от приложения не отличаешь? :)А что операционка не является приложением? Да расскажи мне пожалуста чем это отличается..
Чем ядро ОС не является много поточным приложением.
> Собственно, а какая у монолитного кернела ОС архитектура? Да в общем то
> его собачье дело как оно там внутри себя запросы программ обслужит.
> Поэтому и лепят как получится и как удобно. Даже работает. Монолит
> является относительно лобовой реализацией обслуживалки запросов. Архитектура по принципу
> "так проще всего сделать было".
> Со временем в лине оформились некие подсистемы и границы между ними и
> прочая. Так как было удобно разработчикам которые за все это отвечало.
> Их судя по всему все устраивает, иначе это было бы как-то
> иначе. А остальных это вообще @#$ть не должно ибо внутренняя кухня
> ядра.Это надо взять в рамку - что бы показывать студентам. Почитай пожалуйста книжку http://bookinist.net/books/bookid-193551.html
потом прийдешь расскажешь другим о архитектуре ОС.PS. внутренная кухня ядра интересует очень многих - от разработчиков OpenVZ и Lustre и многих других проектов поменьше.. Тот же РейсерFS.
Считайте что это такое неявное (а местами - очень даже явное) давление - делаешь что-то большое - сиди в основном дереве, а не пытайся свои модули сбоку держать. Как по мне - исключительно правильный подход, способствующий согасованности работы с остальными подсистемами. Что характерно - разработчики OpenVZ это давно поняли и сейчас 90% их кода - в мейнлайне. Люстровцы тоже, вот, поняли. ReiserFS - в ядре. А елси Reiser4 имели в виду - ну что, пора ее спокойно похоронить, раз некому ей заниматься благо альтернатив хватает. Хороший пример, кстати, того, что в принципе хорошо, но в систему не легло, а потому с сожалением - но должно быть похоронено.
> Считайте что это такое неявное (а местами - очень даже явное) давление
> - делаешь что-то большое - сиди в основном дереве, а не
> пытайся свои модули сбоку держать. Как по мне - исключительно правильный
> подход, способствующий согасованности работы с остальными подсистемами. Что характерно
> - разработчики OpenVZ это давно поняли и сейчас 90% их кода
> - в мейнлайне. Люстровцы тоже, вот, поняли.Коментировать даже не хочется. Слишком большая специфика у люстры и завязанность на стабильные дистрибутивы. Я с удовольствием посмотрю как вы уговорите поставить последние ядра в лабораторию ядерной физики Лос-Аламос.
55>>я ничего не предлагаю - я лишь описываю _СВОЙ_ геморой.Фотку в аватар повесь, а то ж не все поняли.
> Коментировать даже не хочется. Слишком большая специфика у люстры
Не надо себя сдерживать!!
> 55>>я ничего не предлагаю - я лишь описываю _СВОЙ_ геморой.
> Фотку в аватар повесь, а то ж не все поняли.зачем? шигорин или его ребята вот один раз пытался сделать портирование - тоже представляют как это весело.
>> Коментировать даже не хочется. Слишком большая специфика у люстры
> Не надо себя сдерживать!!тогда все просто. Глупость говоришь. Люстра заняла свои позиции только из-за Cray - теперь Cray подставили подножку. С таким успехом люстра может скоро уйти из top100 и о ней не вспомнят - как теперь не вспоминают о catamount.
> скоро уйти из top100А почему top100? Когда обычно всех интересует рейтинг top500 все-таки? :)
>> скоро уйти из top100
> А почему top100? Когда обычно всех интересует рейтинг top500 все-таки? :)последние строчки top500 никому не интересны. интересен если уж так брать top10 - первые 10 строк, или первые 100 строк этого рейтинга. Таки надо бы в теме быть.
> Появятся совсем другие и сильно сложнее.Обычно когда у линуксоидов появляются проблемы - они их решают и все в конечном итоге работает. Не вижу чего ради это будет не так в i++'й раз.
> Да - материться у тебя получается. А строить логические цепочки - не очень.
Напротив - я вроде бы вполне логично оценил что применить проприетарщиковскую логику к проприетарщиковским окорокам - весьма забавно.
> Им это кому? Этот патч делал я.
Что, опять ты единолично? Про то что ты EXT4 писал в одно лицо я уже слышал. Но судя по коммит логам EXT4 у меня на этот счет большие сомнения. Почему-то я подозреваю что тут ты тоже сильно приукрасил.
Еще интереснее вот чего: зачем писать драйвера под "нищeбродский" линукс, если есть "чиста канкретные" маки и винды? Как-то странно даже что вы для них драйвера не пишете. Или вы себя к нищeбродам относите?
Данная нестыковка давно вызывает у меня много вопросов.
> Только теперь прийдется делать обратный
> - для поддержки старых ядер (из состава RHEL) в новых клиентах.Бывают в жизни огорчения.
> А что операционка не является приложением?
Я в афиге, дорогая редакция. КрЮтой разработчик, пишущий патчи космического масштаба в ядро ... не знает что ОС не является приложением. Wtf?! O_O
И вы даже не смогли почитать хотя-бы вику? Я в шоке. Вот, извольте: http://en.wikipedia.org/wiki/Application_software
> Да расскажи мне пожалуста чем это отличается..
Тем что под приложением понимают некую прикладную программу, которая непосредственно помогает пользователю в ведении какой-то нужной ему деятельности.
Например GIMP - приложение. Он непосредственно помогает пользователю картинки рисовать. А линевый кернел который это обслуживает - часть ОС. Это не приложение. Собственно, термин "приложение" появился как противопоставление "системному ПО", ОС и тому подобному.
> Чем ядро ОС не является много поточным приложением.
Тем что оно не взаимодействует с пользователем и не решает его задачи напрямую а лишь помогает другим программам это делать. По поводу чего это часть ОС а не приложение.
> потом прийдешь расскажешь другим о архитектуре ОС.
...сказал крутейший разработчик, не знающий что ядро ОС - не приложение :). Забавно. Интересно сколько народа здесь уже делит на ноль в этом треде, глядя на такой цирк? :)
> PS. внутренная кухня ядра интересует очень многих - от разработчиков OpenVZ и
> Lustre и многих других проектов поменьше.. Тот же РейсерFS.Она интересует многих, но по моим наблюдениям простой способ есть 1: затолкать как можно больше в майнлайн как можно меньше держать вне оного. И это очень хорошо: проект имеет тенденцию к интеграции. Что способствует его сохранению и развитию. Намного хуже если происходит наоборот.
> Я в афиге, дорогая редакция. КрЮтой разработчик, пишущий патчи космического масштаба в ядро ... не знает что ОС не является приложением. Wtf?! O_O
> И вы даже не смогли почитать хотя-бы вику? Я в шоке. Вот, извольте:
>http://en.wikipedia.org/wiki/Application_softwareСмешной вы. дальнеший бред коментировать не хочется. У вас слишком ограниченный кругозор.
>> PS. внутренная кухня ядра интересует очень многих - от разработчиков OpenVZ и
>> Lustre и многих других проектов поменьше.. Тот же РейсерFS.
> Она интересует многих, но по моим наблюдениям простой способ есть 1: затолкать
> как можно больше в майнлайн как можно меньше держать вне оного.
> И это очень хорошо: проект имеет тенденцию к интеграции. Что способствует
> его сохранению и развитию. Намного хуже если происходит наоборот.еще раз. Люстра без Cray/HP это весьма и весьма не много. А Cray/HP заинтересованы только в стабильных версиях.
Запихивание в mainline способствует только появлению не совместимых версий - зависит от того в какое время заморозили ядро. При этом сборке под новые ядра RHEL/SLES это не поможет. Так как за время поддержки ядра - люстра разовьется очень сильно и никто не будет бэкпортить новые версии в старые ядра.Если оставить разработку как есть - опять же появляем геморой с тем что какой-то баг будет пофикшен в mainstream - но при этом не в основной и стабильной ветках люстры.
Пока что вся идеология запихивания строится на том что "а патчей в vanila будет не много" (дословный ответ от разработчиков Intel) - но как жить с этим - они опять же не представляют.
> принципами UNIX wayНет никаких принципов "UNIX way", кроме принципа "надо делать хорошо и не надо плохо".
В очередной раз: "предполагают непрерывное увеличение функциональности и связанный с ним рост кодовой базы". Банальная, общая фраза которая описывает путь любого ПО, в любом "вэе".
>Linux 3.11
>3.11А поддержка рабочих групп заявлена?
>>Linux 3.11
>>3.11
> А поддержка рабочих групп заявлена?Linux Chicago не за горами.
> Linux Chicago не за горами.Даешь пингвина на эмпайр стэйт билдинг!
>>>Linux 3.11
>>>3.11
>> А поддержка рабочих групп заявлена?
> Linux Chicago не за горами.даешь СРАЗУ Cairo или Linux 8.1 !! :P
Ничего тупее не придумали? Задолбали.
> Ничего тупее не придумали? Задолбали.Ну так бсдшники же. У них на десктопе максимальная - вот и меряют по себе...
Так это она самая и есть!
Она самая, это про обсуждаемую новость.
Похоже действительно будет годно к использованию с названием: Linux 3.11 for Workgroup