https://www.opennet.ru/openforum/vsluhforumID3/114553.html Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за раздел "staging" в ядре Linux, сообщил (https://lkml.org/lkml/2018/6/1/164) об удалении из ветки linux-next, на основе которой формируется выпуск 4.18, кода кластерной файловой системы Lustre, которая применяется на 70% из 100 крупнейших кластеров. Код Lustre был добавлен (https://www.opennet.ru/opennews/art.shtml?num=37796) в ядро пять лет назад, но с тех пор не продвинулся для перевода из экспериментальной ветки "staging" в число штатных файловых систем. Среди основных причин упоминается отсутствие должной активности по приведению имеющегося кода к соответствию с остальным ядром, плохая адаптация кода к изменениям в VFS, а также игнорирование (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/2018-June/007095.html) проблем и периодическая публикация патчей, ломающих имеющуюся функциональность.<br><br><br>По мнению Грега всю необходимую работу по чистке стиля оформления и адаптации кода можно было провести за 6 месяцев, но по активности разработчиков Lus https://www.opennet.ru/openforum/vsluhforumID3/114553.html#105 Wed, 20 Jun 2018 11:21:44 GMT https://www.beegfs.io последнее время хвалят<br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#100 Sun, 17 Jun 2018 12:55:58 GMT Хнык-Хнык это вы уж придумали. По себе судите? думаю если не нужную коммерческую фигню убить и убрать Linux с всего что в TOP500, думаю вы не обрадуетесь. За одно выкинуть из геодезии, нефтянки (shell, BP, кто там еще на люстре?...), авиационнке (NASA, LM, Boeng...)<br>Останется на одну причину меньше тыкать - о каком-то превосходстве линукса.<br>И станет линукс уделом мадригалов.<br><br>Lustre отлично работал и без встраивания в ядро, больше 20 лет.<br>Встраивание в ядро - внесло только фрагментацию в платформу. Начиная от гемора с модулями которые пересекаются с штатными из ядра, и кончая проблемами interoperability. Клиенты прибегают "а у нас люстра из убунты не монтирует/работает плохо/(дописать по вкусу)" с ваших серверов. А потом выясняется что в убунточке / федоре - код как г.. мамонта и все эти проблемы уже давно исправлены.<br><br>Так что бенефитов от наличия люстры в ядре - ровно 0. А о проблемах предупреждали Андреаса еще с первого захода, но тот твердил себе как попугай, и даже при общении на конференции не пр https://www.opennet.ru/openforum/vsluhforumID3/114553.html#99 Sat, 16 Jun 2018 14:51:21 GMT короче, как обычно: никто не хочет забесплатно поддерживать ненужную им коммерческую фиготень. хнык-хнык.<br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#98 Sat, 16 Jun 2018 04:42:09 GMT Ох.. вот уж эти красно....<br>новость совсем не о том.<br>Новость о том что <br>1) Когда 4 или 5 лет назад влили люстру в ядро - стиль кода в люстре и в ядре отличался очень сильно.<br>Хотя бы тем что в люстре использовались пробелы - а в ядре табы.<br>Одномоментно поменять форматирование по всему коду - это потерять историю.<br>Кроме того - многие части кода являются разделяемыми между сервером и клиентом. А в ядро влили только клиента.<br>Поэтому попытка удалить "не нужные" куски - приводит к конфликтам при обновлении.<br>что в свою очередь привело к сильному расхождению версий между lustre mainstream и lustre in kernel.<br>(о чем андреаса предупреждали не раз - но .. это же круто и молодежно запихать в ядро).<br><br>2) есть налаженный годами процесс разработки - включающий рецензирование кода в gerrit, который не согласуется с пониманием Грега как должна вестись разработка - в его понимании все должно идти через maillist. И ломать работу через герит - никто не хочет. С подобными проблемами сталкивались все крупные проекты котор https://www.opennet.ru/openforum/vsluhforumID3/114553.html#97 Thu, 14 Jun 2018 16:19:00 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt; палки.<br>&gt;&gt; btw. вы видели Ceph, Cluster на 2000 нодах с данными (общий объем <br>&gt;&gt; 20P и выше) и где нить 10000 клиентов.<br>&gt;&gt; Сколько там времени кворум будет собираться когда часть дата нод уйдет в <br>&gt;&gt; offline из-за сетевых косяков?<br>&gt;&gt; Что-то там с клиентами у них? FUSE? ой.. а он сможет выдать <br>&gt;&gt; 10 Gbyte/s на 16 клиентов? Или сдохнет после 10м/с ?<br>&gt;&gt; Что там у нас с random IO - который требует кучу переключений <br>&gt;&gt; контекстов - что очень весело с современными "фиксами" на мельдаун?<br>&gt; пользуюсь glusterfs напрямую, без fuse, чего и всем желаю <br><br>на 10-20 тыс клиентов? вот обещают что в OKR их будет 100 тыс.. <br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#96 Thu, 14 Jun 2018 16:17:25 GMT не за что, рад если это чем-то помогло.<br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#95 Thu, 14 Jun 2018 12:32:03 GMT &gt;[оверквотинг удален]<br>&gt;&gt; не будет печалится о Lustre, которая пишется разработчиками из под <br>&gt;&gt; палки.<br>&gt; btw. вы видели Ceph, Cluster на 2000 нодах с данными (общий объем <br>&gt; 20P и выше) и где нить 10000 клиентов.<br>&gt; Сколько там времени кворум будет собираться когда часть дата нод уйдет в <br>&gt; offline из-за сетевых косяков?<br>&gt; Что-то там с клиентами у них? FUSE? ой.. а он сможет выдать <br>&gt; 10 Gbyte/s на 16 клиентов? Или сдохнет после 10м/с ?<br>&gt; Что там у нас с random IO - который требует кучу переключений <br>&gt; контекстов - что очень весело с современными "фиксами" на мельдаун?<br><br>пользуюсь glusterfs напрямую, без fuse, чего и всем желаю<br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#94 Thu, 14 Jun 2018 12:30:31 GMT &gt; хм.. а можно развернуть "из под палки" ?<br>&gt; Особенно если посмотреть что основные люди как зашли в проект в районе <br>&gt; 2003года, так до сих пор и комитят..<br>&gt; Не сходится как-то с определением "из под палки".<br><br>Ну новость о том, что они не хотят ничего коммитить, будто их не кормят и насилуют, поэтому их код надо либо отдельно сопровождать кому-то, либо выкинуть из ядра.<br> https://www.opennet.ru/openforum/vsluhforumID3/114553.html#93 Thu, 14 Jun 2018 03:36:45 GMT Ещё раз огромное спасибо за ваши комментарии и за ваш опыт!<br>