LINUX.ORG.RU

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

 


0

0

Евгений Поляков предоставил патчи для ядра, реализующие клиент для POHMELFS.

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

http://www.ioremap.net/projects/pohmelfs/

>>> Подробности (LKML)



Проверено: Shaman007 ()

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

lester_dev ★★★★★
()
Ответ на: комментарий от Manhunt

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

kto_tama ★★★★★
()

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

Orlusha ★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

scaldov ★★
()

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

Jayrome ★★★★★
()
Ответ на: комментарий от MaratIK

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

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

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

anonymous
()
Ответ на: комментарий от MaratIK

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

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

huisho
() автор топика

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

WatchCat ★★★★★
()

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

Буду ждать BODUNFS.

anonymous
()

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

Vark
()

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

Syncro ★★★★★
()

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

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

Sun-ch
()
Ответ на: комментарий от Die-Hard

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

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

rtc ★★
()
Ответ на: комментарий от rtc

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

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

rtc ★★
()
Ответ на: комментарий от Guest30

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

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

anonymous
()
Ответ на: комментарий от rtc

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

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

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

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

Die-Hard ★★★★★
()

POH ME LFS ?

anonymous
()

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

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

anonymous
()
Ответ на: комментарий от dimon555

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

anonymous
()

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

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

anonymous
()
Ответ на: комментарий от Die-Hard

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

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

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

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

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

anonymous
()
Ответ на: комментарий от rtc

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

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

anonymous
()
Ответ на: комментарий от Die-Hard

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

anonymous
()
Ответ на: комментарий от huisho

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

tek
()
Ответ на: комментарий от tek

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

Crazy_Doctor
()
Ответ на: комментарий от tek

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

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

rtc ★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

rtc ★★
()
Ответ на: комментарий от Die-Hard

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

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

rtc ★★
()
Ответ на: комментарий от rtc

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

anonymous
()
Ответ на: комментарий от rtc

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

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

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

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от rtc

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.