Выпущен клиент для POHMELFS

Название то какое :-D

> Название то какое :-D

Да, и это не случайно. По ссылке:

> Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>

# mount -t pohmel -o rassol,beer,killwife /head

кеширование , асинхронность , длинные пути , многопоточность , транзакции , кластеризация , балансировка - мечта , одним словом

Похмел под люстрой...

Яндекс вообще молодцы, много чего толкового пишут. Женя Поляков жжот. viva Yandex!

название дурацкое.

>название дурацкое.

жумля-хуюмля тоже как-то не звучит.

жжот - не жжот, но только его kevent'ы в ядро не взяли http://lkml.org/lkml/2006/12/17/58

Русская народная ФС?

А какая связь между хорошим кодом и "взятием" в ядро? NFS вон есть в ядре, но это не мешает ему быть таким п*здецом, что даже страшно представить :) И наоборот, много толковых вещей нет в ядре.

Вон exec-shield тоже нет в ядре, хотя его сам Ingo Molnar из RedHat пишет.

В общем - завидуйте молча :)

ну по кр мере драйвер w1 взяли, мб еще что-то; а за похмел он серьезно взялся, не отступит. и не настолько укурен как Ганс, так что дождется:)

p.s. что-то руки у него дрожали, даже когда он свой мэйл писал: Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mitp.ru>

А кто-нибудь вообще pohmelfs использовал?
Как оно?

Пока рановато переходить.

Буду ждать BODUNFS.

Buzzword bingo!

Да, название и отпугивает и притягивает одновременно :)
Но тоже интересно как оно в деле.

Женя, залогинься.

не иначе как к параду цифр в Unix timestamp зарелизили

http://www.linux.org.ru/view-message.jsp?msgid=2480646

Почитал на опеннете обсуждение POHMELFS -- не уверен, но похоже на очередной велосипед. Есть же Lustre, которая все это с лихвой перекрывает. Автор пеняет ей на то, что Сантехники её неправильно развивают и в конце концов погубят, но как-то неубедительно...

Вообще, я не верю, что один человек сможет написать нечто достойное. Надежда на то, что коммьюнити поддержит, пока оно не слишком разрослось и обозримо -- посмотрим...

>название дурацкое

кому как, например http://zmanda.com/ впечатляет?

А человеку не обязательно писать. Тут главное придумать, как например, один профессор придумал лисп.

>Есть же Lustre, которая все это с лихвой перекрывает.

У люстры (как и у nfs) write-through кэш, а не грамотный write-back, что равносильно тому, что кэша нет вообще - вот была главная точка зрения автора. Поэтому любые операции с метаданными всегда будут на порядок медленнее чем в POHMELFS и (судя по всему умершей) CRFS от Оракла.

а для дома то она нужна? (на локалхосте)

Хорошее название :-)

Почитал подробнее. POHMELFS - это типа клиента к распределенной системе, построенной по принципу distributed hash table, т.е. без выделенных метадата серверов как в Люстре и остальных, что значит принципиально без точек отказа. Похоже на Chord по адресации.

POHMELFS поэтому сейчас представляет из себя что-то вроде pNFS, т.е. сетевая файловая система с параллельным доступом к нескольким серверам, транзакциями и т.п.

>а для дома то она нужна? (на локалхосте)

...разрабатываемая для использования в БОЛЬШИХ вычислительных системах...

> У люстры (как и у nfs) write-through кэш, а не грамотный write-back, что равносильно тому, что кэша нет вообще - вот была главная точка зрения автора.

Ну, как-то мне эта точка зрения не импонирует.

Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше.

Впрочем, я не специалист по FS. С Ластрой я работаю, и вижу, что основная проблема там в том, что она слишком сложная. Если ещё наворотов добавить то, боюсь, вообще не взлетит...

POH ME LFS ?

> # mount -t pohmel -o rassol,beer,killwife /head

killwife -- это опция для монтирования reiserfs вапще-та

а какие ещё есть похожие файловые системы? GFS?

GFS, OCFS, GlusterFS. Все тормоза страшные на метаданных.

Мило звучит вэбмайл www.uebimiau.org

/me подавился лимонадом

очередной велосипед, man lustre уважаемые писатели кластереых и сетевых FS

особенно повеселила фича: паралельная запись :)

прям мои слова Орешек :)

Сантехники люстру и правда неправильно двигают, сильно медленно с одной стороны под руководством тупых менеджеров ниразу не технарей но кот. всем хотят рулить с другой стороны.

В результате новые фичи хер знает когда будут доступными, так, стабильная ветка время от времени баги фикшенные кажет.

Другое отличие от CFS то что в CFS люстра развивалась в направлении нужном большинству или самым жирным кастомерам. В сане же они двигают ее в направлении высосанной из пальца стратегии. Пока это не сильно сказывается ибо мало времени прошло но пока пройдет много времени все загнуться может как уже было неоднократно под сановым патронатом.

На счет одного человека: btrfs - в основном написано одним человеком,  zfs - маленькой командой человек 10 и многие другие хорошие вещи писались маленьким кол. людей.

смотря какие операции с метаданными... есть же icache и dcache системные и их валидной в люстре поддерживается с пом. ldlm и проверяется очень быстро - поиск лока с нужным режимом чтения записи на клиентском ноде. wb cache не самоцель, ну и он усложняет все. Если говорить о метаданных то он например подразумевает disconnected operations, то есть сервера нету а клиент шпилит создает файлы и все такое. Позже сбрасвает на сервер, но такое поведение требует хитрой алокации инодов-объектов, их клиент должен алоцировать а не сервер... в люстре 2.0 так и сделано но когда она будет хер его знает :)

думаю если копнуть похмелфс то результат будет неутешительным. для него :)

добавлять надо грамотно :) вот например есть куча проблем с рекавери. Они в сновном касаются зависимых транзакций. То есть есть 10000 клиентов и все меняют чтото и изменения одних основаы на изменениях других. Если сервер падает, клиенты начинают засылать ему незакомиченные транзации в правильном порядке (по номеру транзакции). Если какой то клиент из тех что посредине упадет в процессе или просто из-за проблем с сетью не приконектится вовремя, остальные клиенты тоже будут заевикчены потому как неизвестно основаны их даные на упавшем или нет и потому с точки зрения целостности данных так безопасней. Для того чтобы пофиксить это была добавлена VBR - version based recovery и COS - commit on share. Последнее отслеживает шаринг с разных клиентов и комитит такое сразу же чтобы избежать сложностей в рекавери. Это в 1.8 будет, но чтото долго оно, задерживается. Эти фиксы уменьшают время рекавери и делают все проще :) по идее с эти должно взлететь

А кто у нас в "двойке" живет? Совсем старый стал, даже и не вспомню.;( Интересно на каком факультете у чуваков столько свободного времени.

>А кто у нас в "двойке" живет?

Кванты, ты чё.

ФФКЭ, они же "кванты". Но вообще-то там и с других факультетов народ бывает. Насчёт свободного времени - он может уже курсе на 5-6 или в аспирантуре и работает, вполне возможно, по специальности. Т.е. у него диплом или диссер вполне по этому похмелфс может быть. Ну или что-то в этом роде. Сейчас, вроде как, появились такие кафедры. Типа информационные технологии и т.п.

>А кто у нас в "двойке" живет? Совсем старый стал, даже и не вспомню.;( Интересно на каком факультете у чуваков столько свободного времени.

Он уж лет 5 как закончил МФТИ.

>смотря какие операции с метаданными... есть же icache и dcache системные и их валидной в люстре поддерживается с пом. ldlm и

Эти кэши не имеют никакого отношения к метаданным - просто маленьких кэш каких-то данных и каких-то инструкций.

>проверяется очень быстро - поиск лока с нужным режимом чтения записи на клиентском ноде. wb cache не самоцель, ну и он усложняет все. Если говорить о метаданных то он например подразумевает disconnected operations, то есть сервера нету а клиент шпилит создает файлы и все такое. Позже сбрасвает на сервер, но такое поведение требует хитрой алокации инодов-объектов, их клиент должен алоцировать а не сервер... в люстре 2.0 так и сделано но когда она будет хер его знает :)

Кстати, автор когда-то давно собирался сделать offline режим - сейчас все будет работать либо до первого синка (который заснет до момента включения сети), либо пока память есть для работы (когда будет мало, снова заснет).

wb-cache хоть все и усложняет, но выигрыш дает огромный. В pohmelfs для этого есть протокол поддержания когерентности на клиентах, что-то типа распределенных блокировок на чтение (может быть много) и на запись (только один лок на объект).

Ну а для любителей люстры - она уже научилась нормально реагировать на пропадание сети? У нее с этим уж очень серьезные проблемы...

Кто заинтересовался - пишите автору, он нормально отвечает, может помочь.

>Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше.

Трудно сказать. Для каких-то операций наверное будет как для write-through, для каких-то быстрее (где редко нужно флашить на сервер). Наверное для случая непрерывной записи в один и тот же файл кучей клиентов будет медленнее.

rtc: Женя, у тебя раздвоение личности :)

Ждем базовую кафедру POHMEL :-)

Как раз то что искал для домашней файлопомойки ^___^

>> Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше.

> Трудно сказать. Для каких-то операций наверное будет как для write-through, для каких-то быстрее (где редко нужно флашить на сервер). Наверное для случая непрерывной записи в один и тот же файл кучей клиентов будет медленнее.

Вот, боюсь, по-любому будет медленнее...

На самом деле, в распределенных файлухах, как я понял (только не принимайте мои слова слишком близко к сердцу -- я решительно не спец и вполне могу неверно интерпретировать слова, что мне говорят специалисты, когда я им жалуюсь на то, что моя аппликуха тормозит на их супре-пупер кластере), не в хэшах проблема, отнюдь...

Мне приходится работать на двух сравнительно больших (тысячи корок) кластерах с Ластрой. Разница между ними в том, что один имеет достаточное кол-во железяк для того, чтобы хранить метаданные, и динамическую маршрутизацию сетки (КвадриксНет2), а в другом оно всё (метаданные) на одном сервере лежит, и под ИБ бегает. На первом кластере я восхищён производительностью FS -- я просто не могу её насытить параллельными бенчмарками, и при этом всё летает в интерактиве! -- во втором случае всё гораздо хуже (самое неприятное -- ждать 2 минуты отклика от команды ls).

ИМХО write-back хэши -- епсилон малое . Но вот усложнить и затормозить всё они могут по самое нехочу...

> ...Это в 1.8 будет, но чтото долго оно, задерживается.

IMHO этого не надо. FS -- не БД.

На самом деле ИМХО распределённые "reliable" файлухи с транзакциями вообще не нужны. Вместо них нужны всякие распределённые БД, Берклиевские Хэши и прочие Ораклы. А распределённые файлухи нужны исключительно для скрэтчей для HPC(High-performance computing).

"Эти кэши не имеют никакого отношения к метаданным - просто маленьких кэш каких-то данных и каких-то инструкций."

что значит не имеют :) я говорю про люстру, в ней очень даже имеют ибо иноды и имена как раз и есть те самые метаданные. Ну плюс еще инфа о страйпах которая приходит от  MDS.

При создании файлов, диров, идет обращение к серверу (MDS) полюбому. С наличием WB кеша этого не не понадобится если клиент сможет алоцировать id объектов без участия сервера.

"В pohmelfs для этого есть протокол поддержания когерентности на клиентах, что-то типа распределенных блокировок на чтение (может быть много) и на запись (только один лок на объект)."

ох умиляют меня эти громкие "науные" названия :) В реальности этот самы протокол всего лишь часть работы ldlm.

Клиенты берут локи с сервера на чтения или запись (на самом деле режимов больше: PW, CW, PR, CR, EX, NL). Лок берется либо на часть объекта описывающего медатанные (условно говоря на часть полей в иноде) или на часть файла с данными (экстент). Данные или метаданные на клиенте кешируются и привязываются к локу. Если сервер или другой клиент берет несовместимый лок (матрица совместимости есть на википедии) все ноды кот. имеют несовместимый лок оповещаются с пом. bl_ast rpc. Для них это сигнал сбросить кеши под несовместимыми локами и отдать локи обратно серверу.

Так как кеширование штука полезная, люстра умеет не ограничивать жестко кол. локов на одном клиенте. Он берет столько сколько позволит его память, память сервера и воркинг патерн. Клиент кот. компилит ядро может взять все локи кластера при условии что остальные клиенты неактивны. Если все будут активны то локи поделятся приблизительно поровну и будут мигрировать туда-сюда по мере того как ктото становится активнее других.

"Ну а для любителей люстры - она уже научилась нормально реагировать на пропадание сети? У нее с этим уж очень серьезные проблемы..."

у нее от рождения умение реагировать на пропадание сети. Благо есть рекавери кот. включает в себя (конкретно для этого случая) реконструкцию рпц на сервере если скажем рпц потерялся по дороге и AT - адаптивные таймауты - умение подстраивать таймауты между нодами в зависимости от состояния сети и загруженности сервера (загруженный сервер может долго не обрабатывать рпц).

Откуда столько яда? :) И кстати, для любителей похмелфс, оно так умеет? У него вообще как с рекавери?

Штука интересная, но ИМХО очередной велосипед котю решит проблемы решенные в люстре лет эдак через 5, если повезет.