Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за раздел "staging" в ядре Linux, сообщил (https://lkml.org/lkml/2018/6/1/164) об удалении из ветки linux-next, на основе которой формируется выпуск 4.18, кода кластерной файловой системы Lustre, которая применяется на 70% из 100 крупнейших кластеров. Код Lustre был добавлен (https://www.opennet.me/opennews/art.shtml?num=37796) в ядро пять лет назад, но с тех пор не продвинулся для перевода из экспериментальной ветки "staging" в число штатных файловых систем. Среди основных причин упоминается отсутствие должной активности по приведению имеющегося кода к соответствию с остальным ядром, плохая адаптация кода к изменениям в VFS, а также игнорирование (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) проблем и периодическая публикация патчей, ломающих имеющуюся функциональность.
По мнению Грега всю необходимую работу по чистке стиля оформления и адаптации кода можно было провести за 6 месяцев, но по активности разработчиков Lustre видно, что они не заинтересованы в этом и поэтому код буксует в "staging" уже пять лет. Раз в несколько месяцев возникают несостыковки с другими подсистемами и Грегу приходится добиваться внесения правок и указывать (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) на ошибки (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) в коде (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...), в то время как за этим должны следить непосредственно разработчики Lustre.
По сути имеется два варианта Lustre: отдельная от основного ядра ветка, в которой ведётся разработка и которая применяется в рабочих кластерах, и вариант в составе основного ядра, в который по возможности переносятся случайные исправления и изменения. Первичной рассматривается собственная ветка, а вариант в штатном ядре поддерживается по остаточному принципу. Грег считает, что ситуация с Lustre отлично демонстрирует принцип, что модель разработки подсистем ядра с двумя отдельными ветками никогда не работает.Вместо поддержания Lustre в "staging" без какого-либо прогресса в развитии, разработчикам данной ФС предлагается адаптировать свою первичную ветку для включения в основной состав ядра. Разработчики Lustre уже выразили (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) готовность (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) предоставить переработанный патч для перевода кода из "staging" в "mainline" c сопровождением в linux-fsdevel (http://vger.kernel.org/vger-lists.html#linux-fsdevel), но Грег Кроа-Хартман настроен скептически (http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...) и не думает, что ситуация изменится.
URL: http://lists.lustre.org/pipermail/lustre-devel-lustre.org/20...
Новость: https://www.opennet.me/opennews/art.shtml?num=48749
А может, и не стоит тащить в главную ветку ядра всё подряд? Под что-то специфическое всегда можно создать отдельные ветки ядра.
> А может, и не стоит тащить в главную ветку ядра всё подряд?такая политика. Емнип давеча были мысли на тему отделения дров от, собсна, ядра, например. Но пока все как есть
давно пора. помню линус говорил что мега-ядро позволяет сделать его быстрее, а потом выкатили динамически подгружыемые модули без потери эффективности.все эти компоненты не дают мне функционала если я ими не пользуюсь, зато открывают дыры в кернел спейс.
FUSE
Для больших HPC?
> Для больших HPC?Больших - это которые под диваном не помещаются?
Ну как-то так, да.
Здорово усложняется поддержка - при изменениях в ядре, естественно, не получится оглядываться на кучу сторонних модулей, о которых никто и не знает. Либо тогда надо таки вводить stable kernel API, что создаст кучу других проблем - от необходимости тащить массу костылей до расцвета блобов.
не нужно костылей. если коллектив не способен адаптировать модуль под "stable kernel api", я сомневаюсь что они способны этот полезный модуль вообще создать.
Костыли понадобятся потом - чтобы сохранять этот "stable kernel API" (на который окажется завязано 100500 сторонних модулей) несмотря на необходимость изменений. Я бы сказал, что пара "stable kernal API nonsense / don't break userland" - одна из важнейших причин успешного развития линукс
пример из compat-rdma, compat-wireless, даже в люстре libcfs (и куча configure checks) говорят что это очень даже нужное.
Все правильно сделал
Когда что-то исключают из линуксового ядра - это почти всегда хорошо. А то слишком жирно.
Раньше говорили прямо противоположное: *смотрите, в нашем крутом линуксе поддерживается всё и вся из коробки, не то что в этой дохлой винде!11*
Времена изменились...
И сейчас говорят. Но это ж iPony...
Покажи мне винду где хотя бы на словах поддреживался Lustre или что то подобное
Ну теперь и линукс не поддерживает, наконец-то догнал вендус по фичам.
> Покажи мне винду где хотя бы на словах поддреживался Lustre или что
> то подобноепроект WINC - windows native client. Существовал в Sun до покупки его Oracle.
Тормозилось отсутствием вменяемого OFED, а сейчас всех устраивает Samba export с люстры.
Опять же - мисье наверно не в курсе pNFS ?
https://www.cohortfs.com/project/windows-nfs-clientsна делах пойдет? один метадата сервер - но так и люстра не так уж давно обзавелась DNE.
Чего жирно? ФС, работающая с обычными файлами, всегда модулем оформлена. Не нужна - не загружай.
На пятый год Орлиный Глаз... Все таки Грег гораздо мягче Линуса.
Это еще неизвестно. Линус обычно ругает или, в крайнем случае, показывает фак с трибуны, а Грег просто идет и выносит твой код из ядра.
вообще-то он кучу раз тыкал их носом, и даже патчи за них делал. а они решили, что теперь грег так и будет за них до конца времён всё чистить. ну, пусть попробуют с линусом такую штуку провернуть теперь, будет весело.
> вообще-то он кучу раз тыкал их носом, и даже патчи за них
> делал. а они решили, что теперь грег так и будет за
> них до конца времён всё чистить. ну, пусть попробуют с линусом
> такую штуку провернуть теперь, будет весело.и кучу раз делали патчи в ядре - не задумываясь что есть что-то в stageing.
Отдельно вспоминается вырезанный global MR в OFED, который разрешен для ULP, но категорически запретили для люстры (коя по сути тот же ULP в этой части).
я все правильно понял ?
> кода кластерной файловой системы Lustre, которая применяется на 70% из 100 крупнейших кластеровИ эту файловую систему, которая применяется на 70% крупнейших кластеров выкинут ?
> я все правильно понял ?
>> кода кластерной файловой системы Lustre, которая применяется на 70% из 100 крупнейших кластеров
> И эту файловую систему, которая применяется на 70% крупнейших кластеров выкинут ?неправильно вы поняли, не применяется ЭТА версия, которую выкинут
> По сути имеется два варианта Lustre: отдельная от основного ядра ветка, в которой ведётся разработка и которая применяется в рабочих кластерах, и вариант в составе основного ядра, в который по возможности переносятся случайные исправления и изменения.
ЕМНИП, в составе ядра был только клиент, он работает во всех дистрибутивах, и позволяет без труда смонтировать lustre где угодно.
Есть ещё серверная часть и два бэкенда для нее:
ldiskfs - для нее требуется специальное патченное ядро
И zfs - код lustre принят в состав проекта zfs on linux и патченное ядро уже не требуется, но требется наличие модулей zfs.Плюс есть пачка отдельных модулей которые необходимы для работы серверной части, они предоставлены и работают почему-то только в Centos.
собираются модули под ubuntu, suse, redhat.
А исходники есть в дебиан и arch.
btw. не путайте божий дар с яшницей - плиз..> ldiskfs - для нее требуется специальное патченное ядро
правильнее сказать иначе. ldiskfs это очень не много патчей на upstream ext4. патченое ядро не требуется, требуются исходники ext4, патчи накладываются в собственном каталоге.
> И zfs - код lustre принят в состав проекта zfs on linuxээ.. что курили то? lustre over zfs использует обычный z-vol API. Видимо спутали с теми улучшениями которые в последнее время засылают в zfs on linux - что бы избавиться от кучи проблем у оригинального порта?
> и патченное ядро уже не требуется, но требется наличие модулей zfs.
> Плюс есть пачка отдельных модулей которые необходимы для работы серверной части, они
> предоставлены и работают почему-то только в Centos.Что курили то? Минимальный набор патчей на ядро - для сборки сервера, это 5 патчей в основном с tunables и поддержка rdonly-disk (нужен для тестирования - заменен на dm flakey).
Набор патчей для ldiskfs - ограничивается
ldiskfs-2.6-rhel6.4.series ldiskfs-3.0-sles11.series ldiskfs-3.12-sles12sp1.series
ldiskfs-2.6-rhel6.5.series ldiskfs-3.0-sles11sp3.series ldiskfs-4.4-sles12sp2.series
ldiskfs-2.6-rhel6.6.series ldiskfs-3.0-sles11sp4.series ldiskfs-4.4-sles12sp3.series
ldiskfs-2.6-rhel6.7.series ldiskfs-3.10-rhel7.2.series ldiskfs-4.4.0-45-ubuntu14+16.series
ldiskfs-2.6-rhel6.8.series ldiskfs-3.10-rhel7.3.series ldiskfs-4.4.0-49-ubuntu14+16.series
ldiskfs-2.6-rhel6.9.series ldiskfs-3.10-rhel7.4.series ldiskfs-4.4.0-62-ubuntu14+16.series
ldiskfs-2.6-rhel6.series ldiskfs-3.10-rhel7.series ldiskfs-4.4.0-73-ubuntu14+16.series
ldiskfs-2.6-sles11.series ldiskfs-3.12-sles12.seriesно при желании все могут сделать их себе сами.
опять же "только CentOS" не катит.
>> И zfs - код lustre принят в состав проекта zfs on linux
> ээ.. что курили то? lustre over zfs использует обычный z-vol API. Видимо
> спутали с теми улучшениями которые в последнее время засылают в zfs
> on linux - что бы избавиться от кучи проблем у оригинального
> порта?Имел ввиду что в проекте zfs on linux уже есть все необходимые патчи для запуска lustre on zfs
>> и патченное ядро уже не требуется, но требется наличие модулей zfs.
>> Плюс есть пачка отдельных модулей которые необходимы для работы серверной части, они
>> предоставлены и работают почему-то только в Centos.
> Что курили то? Минимальный набор патчей на ядро - для сборки сервера,
> это 5 патчей в основном с tunables и поддержка rdonly-disk (нужен
> для тестирования - заменен на dm flakey).Когда я тестил lustre на CentOS 7.4 у меня все без проблем завелось и на стоковом ядре, без наложения каких либо патчей.
Интересовала failover-схема с drbd, т.к. FLR на тот момент еще не зарелизили. Но производительность не особо впечатлила в отличии от той же BeeGFS. Возможно дело в тонком тюнинге или отсутствии указанных вами патчей - не знаю.
> опять же "только CentOS" не катит.
По крайней мере так написанно в официальной wiki: http://wiki.lustre.org/Lustre_2.10.4_Changelog
Но да, выше уже ответили.
> Имел ввиду что в проекте zfs on linux уже есть все необходимые патчи для запуска lustre on zfsБлин. Ну ZVOL это контейнер с транзакциями, большего люстре и не надо. при некотором желании можно вообще в BDB запустить в userland. Вы же не станете говорить что в BDB есть поддержка люстры?
> Интересовала failover-схема с drbd, т.к. FLR на тот момент еще не зарелизили. Но производительность не особо впечатлила в отличии от той же BeeGFS. Возможно дело в тонком тюнинге или отсутствии указанных вами патчей - не знаю.
Для простого failover вам даже FLR не нужен. DRBD или iscsi, нормальная дисковая полка с EBOD - что бы к дискам был их 2х нод. Скорее всего дело в DRBD, который стоило заменить на iscsi (как минимум).
ну или нормальную дисковую полку с EBOD, тогда можно получить 8-10Gb/s с 2х OST (данные реальных тестов).
> По крайней мере так написанно в официальной wiki: http://wiki.lustre.org/Lustre_2.10.4_ChangelogТому кто писал changelog надо дать по ушам. Можно просто глянуть на на test matrix.
> Вы же не станете говорить что в BDB есть поддержка люстры?Ну в анонсах zfs on linux на опеннете об этом часто упоминается как и changelog самого zfs on linux.
> Для простого failover вам даже FLR не нужен. DRBD или iscsi, нормальная
> дисковая полка с EBOD - что бы к дискам был их
> 2х нод. Скорее всего дело в DRBD, который стоило заменить на
> iscsi (как минимум).
> ну или нормальную дисковую полку с EBOD, тогда можно получить 8-10Gb/s с
> 2х OST (данные реальных тестов).Да, согласен, но на тот момент хотелось чего-то бОльшего: репликацию между физически разными серверами и уйти от использования дисковых полок вообще.
Сейчас с релизом FLR такая возможность предумотрена в самой люстре. Очень интересно посмотреть на то как изменятся результаты бенчмарков Lustre с FLR по сравнению с Lustre on DRBD, можно ли будет вырубать OSS "на живую" и какова будет задержка для клиентов.
Обязательно займусь этим как только снова найдется время на это и если не найдется решение получше. Спасибо.
> Ну в анонсах zfs on linux на опеннете об этом часто упоминается как и changelog самого zfs on linux.Нужно найти того кто писал и попросить адрес драг-диллера. Трава у него видать качественная.
Единственная фича zfs к которой приложила руку люстра - это xattr in dnode, иначе xattr операции очень дорогие.
Остальное что вы увидели в changelog у zfs, это оптимизации - которые делают люди люстра тима в Intel.
Благодаря им - хоть как-то можно жить.> Да, согласен, но на тот момент хотелось чего-то бОльшего: репликацию между физически разными серверами и уйти от использования дисковых полок вообще.
1. lustre_rsync (который rsync для изменений по changelog) не подходил?
2. что вы понимаете под репликаций между физически разными серверами?
3. предложите другой метод (кроме FC, ISCSI) что бы раздать кучу дисков в 2 физических сервера одновременно.
> 1. lustre_rsync (который rsync для изменений по changelog) не подходил?Да, была идея поднять две lustre и синхронизировать изменения между ними.
Так как в нашем случае новые данные записываются активно и постоянно, существует вероятная проблема с консистентностью данных. Например как гарантировать то что данные записались в обе фс в каждый конкретный момент времени и будут доступны, даже в случае отключения какого-нибудь из OSS?Второй вопрос с реализацией клиента - он не должен заметить переключения между двумя фс, по сути можно попробовать использовать обычный iscsi multipathing, думаю это может сработать. Спасибо классную идею!
> 2. что вы понимаете под репликаций между физически разными серверами?
Была идея иметь большое количество OSS-серверов поделеные на отказоустойчивые пары,
а на каждой паре держать только один OST (блочное устройство реплицируемое по сети).В случае отказа одного OSS, то OST перезапускался бы на другом.
Идея в том, чтобы отдельно взятые OSS всегда можно было перезагружать без видимых задержек для клиента, и в то же иметь зеркалирование данных.
Как я понял FLR сейчас решает эту задачу и без общего OST.> 3. предложите другой метод (кроме FC, ISCSI) что бы раздать кучу дисков
> в 2 физических сервера одновременно.Есть еще nbd, AoE, но не совсем понял зачем, iscsi работает отлично.
> Второй вопрос с реализацией клиента - он не должен заметить переключения между двумя фс, по сути можно попробовать использовать обычный iscsi multipathing, думаю это может сработать. Спасибо классную идею!Зависит - хватит ли вам одного сервера для хранения данных. Люстра это в первую очередь сетевой страйпинг, когда вам одного OST не хватит для данных файла.
> Была идея иметь большое количество OSS-серверов поделеные на отказоустойчивые пары,
> а на каждой паре держать только один OST (блочное устройство реплицируемое по сети).Это все о контролерах (серверах) а дисковые хранилища то как? так же полная дупликация?
>В случае отказа одного OSS, то OST перезапускался бы на другом.это типичный кейс люстры. Правда требует что бы данные были доступны на втором OSS. Это решает iSCSI multipath (как вы заметили) или EBOD с дисковой полки в 2 контролера.
FLR - да позволяет иметь 2 копии, но только одна из них writetable.
> Есть еще nbd, AoE, но не совсем понял зачем, iscsi работает отлично.
у вас есть диски сами по себе, их надо как-то отдать на 2 хоста или зеркалить данные. Если у вас данные изменяются часто, у вас весь сетевой трафик может быть забит одной синхронизацией. Тогда уже sync over SAS или похоже технологии.
Кажется мы друг друга немного недопоняли :)> Зависит - хватит ли вам одного сервера для хранения данных. Люстра это
> в первую очередь сетевой страйпинг, когда вам одного OST не хватит
> для данных файла.Серверов по прежнему планируется много, и на каждом из них будет по отдельному OST. Проблем с количеством нод быть не должно.
Под это добро планировалось использовать внутренние диски блейд-серверов. Дупликацию должен был обеспечить drbd, синхронизируя блочные устройства по сети.> это типичный кейс люстры. Правда требует что бы данные были доступны на
> втором OSS. Это решает iSCSI multipath (как вы заметили) или EBOD
> с дисковой полки в 2 контролера.Или drbd как я сказал выше, но идея себя не оправдала.
> FLR - да позволяет иметь 2 копии, но только одна из них
> writetable.О, а об этом можно поподробнее? - если нода с writetable копией отключится, lustre переключит операции записи на другую копию?
> Кажется мы друг друга немного недопоняли :)Возможно, я привык оперировать слегка другими задачами.
>Серверов по прежнему планируется много, и на каждом из них будет по отдельному OST. Проблем с количеством нод быть не должно.
> Под это добро планировалось использовать внутренние диски блейд-серверов. Дупликацию должен был обеспечить drbd, синхронизируя блочные устройства по сети.Дело не в количестве нод, а в простом факте - если у вас умрет нода в процессе репликации - вам только в морг.
все журналируемые FS - строятся на одном простом факте, если сработал journal commit - то данные попали на persistent storage. и точка. Если по какой-то причине FUA и тп - не отработали - и flush данных не обеспечен - вместо FS получите венегрет. Простейший пример - это raid контролер со своей памятью, но без батарейки.
Вот вы пытались сделать именно такое.Будет или медленно или нестабильно или другие инструменты нужны.
> FLR - да позволяет иметь 2 копии, но только одна из них
> writetable.
> О, а об этом можно поподробнее? - если нода с writetable копией отключится, lustre переключит операции записи на другую копию?Обещали что в итоге будет возможность автоматического переключения - в результате вторая реплика станет активной.
Но ценой вопроса может оказаться синхронная запись в phase1, а async recovery - помоему в phase 3?
Ещё раз огромное спасибо за ваши комментарии и за ваш опыт!
не за что, рад если это чем-то помогло.
> я все правильно понял ?нет. ты даже не смог прочитать новость — какое там «понимание»…
//offtop
подскажите что сейчас стоит использовать linux в качестве "распределённого raid1/5/6" на два компа (в соседних комнатах)?
и как такое принято делать?
а куда ты собрался распределять 5 и 6 по двум узлам? зеркало - два таргета iscsi объединить через mdadm
> а куда ты собрался распределять 5 и 6 по двум узлам? зеркало
> - два таргета iscsi объединить через mdadmещё есть ноут (даже два)
цель - домашняя защита от вылета диска (ну и ноут могут и увезти на выходные, гг)
спасибо
В вашем кейсе смысла в сетевом raid нет. Нужна репликация на уровне файлов.
Я бы предложил syncthing или resilio.
> В вашем кейсе смысла в сетевом raid нет. Нужна репликация на уровне
> файлов.
> Я бы предложил syncthing или resilio.мне бы прозрачно для юзерских программ и, желательно, с блокировкой до получения изменённых блоков в реалтайме при попытке чтения/записи (при попытке развернуть/удалить/переименовать одну и ту же фоточку с двух ноутов одновременно)
как я понял syncthing и resilio - аналог rsync_в_кластер ?
> мне бы прозрачно для юзерских программ и, желательно, с блокировкой до получения
> изменённых блоков в реалтайме при попытке чтения/записи (при попытке развернуть/удалить/переименовать
> одну и ту же фоточку с двух ноутов одновременно)
> как я понял syncthing и resilio - аналог rsync_в_кластер ?Не совсем, скорее как торрент только для синхронизации файлов.
Блокировку не предоставляет, но конфликты разрешать умеет. Частично синхронизировать изменеия вроде тоже умеет, прозрачно для приложений - так что для фоточек - самое оно.
>> а куда ты собрался распределять 5 и 6 по двум узлам? зеркало
>> - два таргета iscsi объединить через mdadm
> ещё есть ноут (даже два)
> цель - домашняя защита от вылета диска (ну и ноут могут и
> увезти на выходные, гг)
> спасибоglusterfs, только надо призадуматься планированием размещения её кусков и кворумом
Я в похожем случае собирался поиграться с Тахо (Tahoe, как озеро), но решил что классической бэкап на основе Бакулы мне подойдёт больше, чем репликация.
Gluster. Он глючный и тормозной, но под файлшару нормально.
> Gluster. Он глючный и тормозной, но под файлшару нормально.Это вы о чем ? Может просто научиться читать документацию ? ;-)
Он работает в составе RHEV, не стоит говорить такие глупости.
Дополню его мысль: он глючный, тормозной, но пользоваться вполне можно. Особенно когда rhev сам чототам в тихаря оркестрирует и прячет косяки.
Достойный ответ :)
А чем нынче можно пошарить файлы между несколькими серверами в разных ДЦ, в т.ч. одним виндовым хостом? По возможности чтобы секурность была средствами ФС, без наворачивания поверх VPN
Ceph/gluster
Для виндузей отдельный iscsi/samba шлюз.
> А чем нынче можно пошарить файлы между несколькими серверами в разных ДЦ,
> в т.ч. одним виндовым хостом? По возможности чтобы секурность была средствами
> ФС, без наворачивания поверх VPNНу WebDAV например, хотя зависит от конкретных задач. А в чем сложность наворачивания поверх VPN или IPsec?
https://www.beegfs.io последнее время хвалят
dkms модули, не?
И как дкмс поможет с кривизной кода, фидорасенька юная?
Так, что это перестанет быть болью инженеров из Linux Foundation.
Лучше бы btrfs выкинули.
Зря ты так. У меня на VPS серверах она используется. Как бы я выполнял горячее резервное копирование без неё, даже не знаю. Не платить же операторам за снапшоты, которые в том же датацентре хранятся.
lvm thin volumes
При существующих стабильных проектах Gluster и Ceph, думаю никто
не будет печалится о Lustre, которая пишется разработчиками из под
палки.
хм.. а можно развернуть "из под палки" ?
Особенно если посмотреть что основные люди как зашли в проект в районе 2003года, так до сих пор и комитят..Не сходится как-то с определением "из под палки".
> хм.. а можно развернуть "из под палки" ?
> Особенно если посмотреть что основные люди как зашли в проект в районе
> 2003года, так до сих пор и комитят..
> Не сходится как-то с определением "из под палки".Ну новость о том, что они не хотят ничего коммитить, будто их не кормят и насилуют, поэтому их код надо либо отдельно сопровождать кому-то, либо выкинуть из ядра.
Ох.. вот уж эти красно....
новость совсем не о том.
Новость о том что
1) Когда 4 или 5 лет назад влили люстру в ядро - стиль кода в люстре и в ядре отличался очень сильно.
Хотя бы тем что в люстре использовались пробелы - а в ядре табы.
Одномоментно поменять форматирование по всему коду - это потерять историю.
Кроме того - многие части кода являются разделяемыми между сервером и клиентом. А в ядро влили только клиента.
Поэтому попытка удалить "не нужные" куски - приводит к конфликтам при обновлении.
что в свою очередь привело к сильному расхождению версий между lustre mainstream и lustre in kernel.
(о чем андреаса предупреждали не раз - но .. это же круто и молодежно запихать в ядро).2) есть налаженный годами процесс разработки - включающий рецензирование кода в gerrit, который не согласуется с пониманием Грега как должна вестись разработка - в его понимании все должно идти через maillist. И ломать работу через герит - никто не хочет. С подобными проблемами сталкивались все крупные проекты которые живут в ядре.
Кто-то перешел на полную работу в ядре - кто-то нет.3) высокий порог вхождения - те кто понимают как работает люстра изнутри и могут слать нормальные патчи (Шигонин и его товарищи из T-platform к слову не осилили нормальные патчи на люстру, а единственный патч что видел - состоял из хаков, так что его пришлось переписать), и так работают там где за это платят. Поэтому от комьюнити выхлоп минимальный. Что создает впечатление что оно никому не надо.
4) Наличие большого количества артефактов в сетевой подсистеме. Infinband support был написан в 2006 или 2008 году, с тех пор в OFED все поменялось, а там так и остался код слегка подкрашенный и подпиленый. На что и указывают маинтейнеры OFED. Что поделать толковых спецов по OFED там почти нету.
5) Когенетность namei кэшей между двумя нодами - не тривиальная задача при текущем VFS в ядре. Реализуемая, но путем нестандартных шагов. Что не очень нравится маинтейнерам VFS, которым не хочется напрыгаться и думать еще в эту сторону. Повторяется ситуация с РейсерФС.
и тд.
короче, как обычно: никто не хочет забесплатно поддерживать ненужную им коммерческую фиготень. хнык-хнык.
Хнык-Хнык это вы уж придумали. По себе судите? думаю если не нужную коммерческую фигню убить и убрать Linux с всего что в TOP500, думаю вы не обрадуетесь. За одно выкинуть из геодезии, нефтянки (shell, BP, кто там еще на люстре?...), авиационнке (NASA, LM, Boeng...)
Останется на одну причину меньше тыкать - о каком-то превосходстве линукса.
И станет линукс уделом мадригалов.Lustre отлично работал и без встраивания в ядро, больше 20 лет.
Встраивание в ядро - внесло только фрагментацию в платформу. Начиная от гемора с модулями которые пересекаются с штатными из ядра, и кончая проблемами interoperability. Клиенты прибегают "а у нас люстра из убунты не монтирует/работает плохо/(дописать по вкусу)" с ваших серверов. А потом выясняется что в убунточке / федоре - код как г.. мамонта и все эти проблемы уже давно исправлены.Так что бенефитов от наличия люстры в ядре - ровно 0. А о проблемах предупреждали Андреаса еще с первого захода, но тот твердил себе как попугай, и даже при общении на конференции не признавал проблем.
> При существующих стабильных проектах Gluster и Ceph, думаю никто
> не будет печалится о Lustre, которая пишется разработчиками из под
> палки.btw. вы видели Ceph, Cluster на 2000 нодах с данными (общий объем 20P и выше) и где нить 10000 клиентов.
Сколько там времени кворум будет собираться когда часть дата нод уйдет в offline из-за сетевых косяков?Что-то там с клиентами у них? FUSE? ой.. а он сможет выдать 10 Gbyte/s на 16 клиентов? Или сдохнет после 10м/с ?
Что там у нас с random IO - который требует кучу переключений контекстов - что очень весело с современными "фиксами" на мельдаун?
>[оверквотинг удален]
>> не будет печалится о Lustre, которая пишется разработчиками из под
>> палки.
> btw. вы видели Ceph, Cluster на 2000 нодах с данными (общий объем
> 20P и выше) и где нить 10000 клиентов.
> Сколько там времени кворум будет собираться когда часть дата нод уйдет в
> offline из-за сетевых косяков?
> Что-то там с клиентами у них? FUSE? ой.. а он сможет выдать
> 10 Gbyte/s на 16 клиентов? Или сдохнет после 10м/с ?
> Что там у нас с random IO - который требует кучу переключений
> контекстов - что очень весело с современными "фиксами" на мельдаун?пользуюсь glusterfs напрямую, без fuse, чего и всем желаю
>[оверквотинг удален]
>>> палки.
>> btw. вы видели Ceph, Cluster на 2000 нодах с данными (общий объем
>> 20P и выше) и где нить 10000 клиентов.
>> Сколько там времени кворум будет собираться когда часть дата нод уйдет в
>> offline из-за сетевых косяков?
>> Что-то там с клиентами у них? FUSE? ой.. а он сможет выдать
>> 10 Gbyte/s на 16 клиентов? Или сдохнет после 10м/с ?
>> Что там у нас с random IO - который требует кучу переключений
>> контекстов - что очень весело с современными "фиксами" на мельдаун?
> пользуюсь glusterfs напрямую, без fuse, чего и всем желаюна 10-20 тыс клиентов? вот обещают что в OKR их будет 100 тыс..
Люстрировали...