Грег Кроа-Хартман (Greg Kroah-Hartman) включил (http://www.ioremap.net/node/161) в "staging" ветку Linux ядра код высокопроизводительной распределенной сетевой файловой системы POHMELFS (http://www.ioremap.net/projects/pohmelfs), разработанной Евгением Поляковым. Если при проверке кода в "staging" ветке не возникнет проблем и тестирование пройдет успешно, то в будущем Грег пообщел рекомендовать код POHMELFS для помещения в основное дерево исходных текстов Linux ядра 2.6.30.
В настоящее время реализация POHMELFS включает в себя около 12 тыс. строк кода. По заявлению (http://www.ioremap.net/node/158) Евгения Полякова все основные функции POHMELFS реализованы, осталось исправить некоторые известные ошибки. Последние тесты демонстрируют (tar и dbench (http://www.ioremap.net/node/156), dbench (http://www.ioremap.net/node/153), iozone (http://www.ioremap.net/node/134)) на порядок более высокую производительность, по сравнению с NFS.
Наиболее интересные особенности POHMELFS:-...
URL: http://www.ioremap.net/node/161
Новость: http://www.opennet.me/opennews/art.shtml?num=20315
А ребрендинг это ФС не предполагается?
А зачем ?
Продаваться в отдельно взятой стране плохо будет -- клиенты в укатайке будут.
>Продаваться в отдельно взятой стране плохо будет -- клиенты в укатайке будут.
>Для этого есть сервер со скучным названием fserver и распределенное хранилище с чуть менее скучным названием elliptics network.
Интересно как userland сервер могут включить в ядро?
Может речь идет только о клиенте?
Самое забавное, что ФС на удивление неплоха :)
>Самое забавное, что ФС на удивление неплоха :)Из блога автора
$ time (find /mnt/testdir | wc -l )
3963
POHMELFS: 1m1.493s
NFS: 0m2.521sну собственно проиграть на порядк NFS - это уже неплоха?
читаем дальше:
Local coherent cache for data and metadata. (Byte-range) locking. Locks were prepared to be byte-range, but since all Linux filesystems lock the whole inode, it was decided to lock the whole object during writing. Actual messages being sent for locking/cache coherency protocol are byte-range, but because the whole inode is locked, lock is cached, so range actually is equal to the inode size.
----
в вольном пересказе - один клиент открыл на запись, остальные отдыхают и ждут пока он закончит. Ну еще вопросы с таймаутами и тп.
На workload когда каждый клиент пишет в свой файл оно может и лучше - но объясните зачем там надо distributed FS ?
А round-robin прикрутить. Очереди, со своим гипервизором, уже им разруливать по блочным FS
>А round-robin прикрутить. Очереди, со своим гипервизором, уже им разруливать по блочным
>FSГде-то видимо урожай травы удался на славу =)
>POHMELFS: 1m1.493s
> NFS: 0m2.521s
>
>ну собственно проиграть на порядк NFS - это уже неплоха?Ну да, а то, что он дальше пишет из-за чего это, и как все исправить, ты конечно опустил. Как и остальные тесты :) Объективно, что скажешь...
>читаем дальше:
>Local coherent cache for data and metadata. (Byte-range) locking. Locks were prepared
>to be byte-range, but since all Linux filesystems lock the whole
>inode, it was decided to lock the whole object during writing.
>Actual messages being sent for locking/cache coherency protocol are byte-range, but
>because the whole inode is locked, lock is cached, so range
>actually is equal to the inode size.
>----
>в вольном пересказе - один клиент открыл на запись, остальные отдыхают и
>ждут пока он закончит. Ну еще вопросы с таймаутами и тп.Во-первых, так же происходит и при записи в обычный файл на локальной файловой системе. Во-вторых, там не лок берется, а делегируется право записи, как я понял, это как leases.
>>POHMELFS: 1m1.493s
>> NFS: 0m2.521s
>>
>>ну собственно проиграть на порядк NFS - это уже неплоха?
>
>Ну да, а то, что он дальше пишет из-за чего это, и
>как все исправить, ты конечно опустил. Как и остальные тесты :)
>Объективно, что скажешь...
>Остальные тесты - для случая одного клиента. Что этим хотелось померять?
Нету не lock contention между клиентами, передачи данных между клиентами нету - не посмотриш как влияют эти факторы на работу клиентов и сети.
Только упоминается сделать бы тест когда 10 клиентов по очереди читают по 10 байт с разными смещением - но результатов этого не видно.
Просмотрел? тогда пожалуста ссылку на такой тест.
Вот все тесты:
* metadata intensive load (tar, dbench with lots of threads)
* POHMELFS, NFS and DST in iozone and bonnie++ benchmarks
* the power of local metadata cache fun benchmark (take this dbench single-threaded test not too seriously)
* old iozone tests
Все тесты выполняются с одного клиента - по сути никаких DLM конфликтов нету и все зависит от локальной VFS.где тесты скорость передачи чтения/записи в зависимости от количества клиентов, количества сторадж серверов - нету или просмотрел? Отдельно для случаев когда идет паралельная запись на разные машины в массиве, и когда один дисковый массив. И рядом табличку с параметрами массива без учета pohmellfs - что бы можно было оценить влияние FS на производительность.
Где тот же racer на нескольких нодах?
И тп..>[оверквотинг удален]
>>Actual messages being sent for locking/cache coherency protocol are byte-range, but
>>because the whole inode is locked, lock is cached, so range
>>actually is equal to the inode size.
>>----
>>в вольном пересказе - один клиент открыл на запись, остальные отдыхают и
>>ждут пока он закончит. Ну еще вопросы с таймаутами и тп.
>
>Во-первых, так же происходит и при записи в обычный файл на локальной
>файловой системе. Во-вторых, там не лок берется, а делегируется право записи,
>как я понял, это как leases.Написано что это лок а не lease - только он выполняет роль глобального i_mutex, что хорошо только в случае когда у тебя только один клиент работает с файлом. Для всего остального есть варианты значительно лучше по производительности.
>[оверквотинг удален]
>>
>>Ну да, а то, что он дальше пишет из-за чего это, и
>>как все исправить, ты конечно опустил. Как и остальные тесты :)
>>Объективно, что скажешь...
>>
>
>Остальные тесты - для случая одного клиента. Что этим хотелось померять?
>Нету не lock contention между клиентами, передачи данных между клиентами нету -
>не посмотриш как влияют эти факторы на работу клиентов и сети.
>Кстати в догонку - интресный тест получается в таком workload.
N клиентов - по очереди открывают файл как open(O_RW|O_TRUNCATE) и пишут так что бы попало на несколько слайсов - посмотреть как себя будет вести в случае byte-range lock ping-pong и discard data.
Отоже самое - только open(O_APPEND).
ну и для комплекта MPI fsx test.Автор покажет результаты таких тестов? и в сравнении с GFS, NFS, pNFS, Lustre.
я бы с удовольствием поглядел на результаты и обсудил их.
>Остальные тесты - для случая одного клиента. Что этим хотелось померять?
>Нету не lock contention между клиентами, передачи данных между клиентами нету -
>не посмотриш как влияют эти факторы на работу клиентов и сети.Смешно. А тот тест, который ты цитируешь - он какое-то отношение к этому имеет? :)
Автор не побоялся показать, где _сейчас_ его файловая система ведет себя плохо, как это объясняется, и как будет исправлено. А ты тут же прибежал с какой-то синтетикой.
>Только упоминается сделать бы тест когда 10 клиентов по очереди читают по
>10 байт с разными смещением - но результатов этого не видно.Читатели параллельно обращаются к данным.
>[оверквотинг удален]
>Все тесты выполняются с одного клиента - по сути никаких DLM конфликтов
>нету и все зависит от локальной VFS.
>
>где тесты скорость передачи чтения/записи в зависимости от количества клиентов, количества сторадж
>серверов - нету или просмотрел? Отдельно для случаев когда идет паралельная
>запись на разные машины в массиве, и когда один дисковый массив.
>И рядом табличку с параметрами массива без учета pohmellfs - что
>бы можно было оценить влияние FS на производительность.
>Где тот же racer на нескольких нодах?
>И тп..Снова очень смешно. Почитайте, как позиционирует автор POHMELFS, какие у нее возможности по работе с распределенными серверами и т.п. Сейчас это навороченный NFS с локальным кэшем, а все распределенные вычисления будут делаться сервером, который будет работать абсолютно по другой технологии по сравнению с традиционными системами типа lustre (с ее mds).
>>Во-первых, так же происходит и при записи в обычный файл на локальной
>>файловой системе. Во-вторых, там не лок берется, а делегируется право записи,
>>как я понял, это как leases.
>
>Написано что это лок а не lease - только он выполняет роль
>глобального i_mutex, что хорошо только в случае когда у тебя только
>один клиент работает с файлом. Для всего остального есть варианты значительно
>лучше по производительности.Не знаю, почему он назвал его локом, наверное потому что нет известного словосочетания для read/write leases, которые соответстовали бы поведению.
Касательно глобального i_mutex - он же есть и в lustre, и dlm его никак не "улучшает" :)
Заодно можно погуглить на предмет статистики использования файлов в очень больших сетях и необходимости (оправданности) byte-range блокировок вместо всех этих синтетических тестов.
>
>>Остальные тесты - для случая одного клиента. Что этим хотелось померять?
>>Нету не lock contention между клиентами, передачи данных между клиентами нету -
>>не посмотриш как влияют эти факторы на работу клиентов и сети.
>
>Смешно. А тот тест, который ты цитируешь - он какое-то отношение к
>этому имеет? :)для partial page write - надо прочитать кусок страницы с другого клента который загрязнил страницу - модифицировать - отдать другому клиенту. Кроме того это позволяет оценить производительность операций с локами и network latency.
racer - просто оценка производительности metadata операций.
>
>Автор не побоялся показать, где _сейчас_ его файловая система ведет себя плохо,
>как это объясняется, и как будет исправлено. А ты тут же
>прибежал с какой-то синтетикой.Это не синтетика - это требования по оптимизации предьявляемые cray/llnl/ornl.
Синтетика это tar -xf на одном клиенте.>
>>Только упоминается сделать бы тест когда 10 клиентов по очереди читают по
>>10 байт с разными смещением - но результатов этого не видно.
>
>Читатели параллельно обращаются к данным.Да? помоему тут чтение + запись + partical page write - интерсно поведение данной FS
>
>>[оверквотинг удален]
>
>Снова очень смешно. Почитайте, как позиционирует автор POHMELFS, какие у нее возможности
>по работе с распределенными серверами и т.п. Сейчас это навороченный NFS
>с локальным кэшем, а все распределенные вычисления будут делаться сервером, который
>будет работать абсолютно по другой технологии по сравнению с традиционными системами
>типа lustre (с ее mds).Переведу в другие слова - меня интересует scalability в текущем варианте. Для метадата, для IO между клиентами, между клиентами и стораджами. Обсуждать scalability в случае одного клиента - когда не может возникнуть конфликт локов, как-то странно. Неправда ли?
>[оверквотинг удален]
>>Написано что это лок а не lease - только он выполняет роль
>>глобального i_mutex, что хорошо только в случае когда у тебя только
>>один клиент работает с файлом. Для всего остального есть варианты значительно
>>лучше по производительности.
>
>Не знаю, почему он назвал его локом, наверное потому что нет известного
>словосочетания для read/write leases, которые соответстовали бы поведению.
>
>Касательно глобального i_mutex - он же есть и в lustre, и dlm
>его никак не "улучшает" :)в люстре нету глобального i_mutex, локи на данные - это byte-ranges. Иначе называемце extent lock. Поэтому 2 записи по разным смещениям в один файл на разных клиентах - будет спокойно выполнена. чтение + запись на непересекающися диапазоны.
>Заодно можно погуглить на предмет статистики использования файлов в очень больших сетях
>и необходимости (оправданности) byte-range блокировок вместо всех этих синтетических тестов.измени - но смешно. byte-range и ldlm extent lock - это одно и тоже.
>>Смешно. А тот тест, который ты цитируешь - он какое-то отношение к
>>этому имеет? :)
>
>для partial page write - надо прочитать кусок страницы с другого клента
>который загрязнил страницу - модифицировать - отдать другому клиенту. Кроме того
>это позволяет оценить производительность операций с локами и network latency.
>racer - просто оценка производительности metadata операций.Ты процитировал тест с find /mnt там этого ничего нет. Чувствую, что ты не вникаешь в суть того, что тебе говорят.
>>Автор не побоялся показать, где _сейчас_ его файловая система ведет себя плохо,
>>как это объясняется, и как будет исправлено. А ты тут же
>>прибежал с какой-то синтетикой.
>
>Это не синтетика - это требования по оптимизации предьявляемые cray/llnl/ornl.
>Синтетика это tar -xf на одном клиенте.:) вот ты смешной. Ну напиши автору, что ему нужно протестировать, чтобы тебе понравилось.
Автор утверждал, что метаданные ускоряются - утверждал. Доказал? Доказал.
А тут приходит умка и говорит, что ему это не интересно, а нужно что-то еще...>>>Только упоминается сделать бы тест когда 10 клиентов по очереди читают по
>>>10 байт с разными смещением - но результатов этого не видно.
>>
>>Читатели параллельно обращаются к данным.
>
>Да? помоему тут чтение + запись + partical page write - интерсно
>поведение данной FSДядя, ты хотя бы _свой_ креатиф читай! Какой partial page write и запись? Видишь, что выше процитировано? "10 клиентов по очереди читают по 10 байт с разными смещением" - это твои слова.
>Переведу в другие слова - меня интересует scalability в текущем варианте. Для
>метадата, для IO между клиентами, между клиентами и стораджами. Обсуждать scalability
>в случае одного клиента - когда не может возникнуть конфликт локов,
>как-то странно. Неправда ли?Ну так не обсуждай! Автор показал результаты своих тестов для определенных задач, для других задач не показал. Может быть там все плохо, а может хорошо, но умка сделал вывод даже не задумываясь :)
>>Касательно глобального i_mutex - он же есть и в lustre, и dlm
>>его никак не "улучшает" :)
>
>в люстре нету глобального i_mutex, локи на данные - это byte-ranges. Иначе
>называемце extent lock. Поэтому 2 записи по разным смещениям в один
>файл на разных клиентах - будет спокойно выполнена. чтение + запись
>на непересекающися диапазоны.Lustre перестала пользоваться ext3? В ней отличный i_mutex, как и в линуксовом VFS вообще.
>>Заодно можно погуглить на предмет статистики использования файлов в очень больших сетях
>>и необходимости (оправданности) byte-range блокировок вместо всех этих синтетических тестов.
>
>измени - но смешно. byte-range и ldlm extent lock - это одно
>и тоже.Чорд, весело :) Ты вообще читал, на что ответил? Или просто увидел пару знакомых слов и тут же написал свое мнение о них? Перечитай еще раз, что там написано, и подумай, к чему ты приплел то, что какие-то внутренние локи Lustre одинаковые? Ну как, получилось?
Я хоть похмелфс и не знаю в деталях, но по крайней мере стараюсь адекватно судить о том, что вижу, а не пытаюсь облить грязью то, в чем даже не пробовал разобраться. Отличные в Люстре разработчики, за светом глаз не видят вообще ничего.
>>>Смешно. А тот тест, который ты цитируешь - он какое-то отношение к
>>>этому имеет? :)
>>
>>для partial page write - надо прочитать кусок страницы с другого клента
>>который загрязнил страницу - модифицировать - отдать другому клиенту. Кроме того
>>это позволяет оценить производительность операций с локами и network latency.
>>racer - просто оценка производительности metadata операций.
>
>Ты процитировал тест с find /mnt там этого ничего нет. Чувствую, что
>ты не вникаешь в суть того, что тебе говорят.не придумывай.
>[оверквотинг удален]
>>>Автор не побоялся показать, где _сейчас_ его файловая система ведет себя плохо,
>>>как это объясняется, и как будет исправлено. А ты тут же
>>>прибежал с какой-то синтетикой.
>>
>>Это не синтетика - это требования по оптимизации предьявляемые cray/llnl/ornl.
>>Синтетика это tar -xf на одном клиенте.
>
>:) вот ты смешной. Ну напиши автору, что ему нужно протестировать, чтобы
>тебе понравилось.
>Автор утверждал, что метаданные ускоряются - утверждал. Доказал? Доказал.где доказал? Он продемонтрировал работу с одного клиента, который как выяснилось в случае readdir() + stat() проигрывает реализации операции readdir+ в NFS, я попросил показать случаи с кучей клиентов - посмотреть маштабирование. Маштабирование в зависимости от количества клиентов, в зависимости от offset в файле, количества локов на клиенте и тп.
>А тут приходит умка и говорит, что ему это не интересно, а
>нужно что-то еще...У нас есть сетевая FS у которой заявлен паралельный доступ к файлам - помоему логично увидеть scalability этого решения. Или можно получить второй GPFS - с 16 клиентами уже начинаются тормоза.
>[оверквотинг удален]
>>>>10 байт с разными смещением - но результатов этого не видно.
>>>
>>>Читатели параллельно обращаются к данным.
>>
>>Да? помоему тут чтение + запись + partical page write - интерсно
>>поведение данной FS
>
>Дядя, ты хотя бы _свой_ креатиф читай! Какой partial page write и
>запись? Видишь, что выше процитировано? "10 клиентов по очереди читают по
>10 байт с разными смещением" - это твои слова.Ок, признаю что изначально описал один тест, тут ошибся.
Я имел ввиду тест когда читают и пишут в режиме append по 10 байт на разных нодах.
Это тригерит partical page read/write, весьма частная ситуация - если write()/read() размеры и offset не выровнены по странице.>
>>Переведу в другие слова - меня интересует scalability в текущем варианте. Для
>>метадата, для IO между клиентами, между клиентами и стораджами. Обсуждать scalability
>>в случае одного клиента - когда не может возникнуть конфликт локов,
>>как-то странно. Неправда ли?
>
>Ну так не обсуждай! Автор показал результаты своих тестов для определенных задач,
>для других задач не показал. Может быть там все плохо, а
>может хорошо, но умка сделал вывод даже не задумываясь :)Я вобще попросил результаты тестов - что бы сделать решение.
Результаты lock/data ping pong, short read with partical page read/write и сказал что дальше можно обсуждать после того как увидим результаты.
Цитата нужна или найдешь по треду?>[оверквотинг удален]
>>>Касательно глобального i_mutex - он же есть и в lustre, и dlm
>>>его никак не "улучшает" :)
>>
>>в люстре нету глобального i_mutex, локи на данные - это byte-ranges. Иначе
>>называемце extent lock. Поэтому 2 записи по разным смещениям в один
>>файл на разных клиентах - будет спокойно выполнена. чтение + запись
>>на непересекающися диапазоны.
>
>Lustre перестала пользоваться ext3? В ней отличный i_mutex, как и в линуксовом
>VFS вообще.Откуда в lustre client ext3? его там не было никогда. Были патчи для сервера - поверх ext3. Которыми сейчас пользуется вся linux community - это называется ext4.
На клиенте все IO асинхронно - клиентский i_mutex не важен, для защиты данных вполне хватает byte-range lock (ldlm extent lock в терминах люстры).>[оверквотинг удален]
>>>Заодно можно погуглить на предмет статистики использования файлов в очень больших сетях
>>>и необходимости (оправданности) byte-range блокировок вместо всех этих синтетических тестов.
>>
>>измени - но смешно. byte-range и ldlm extent lock - это одно
>>и тоже.
>
>Чорд, весело :) Ты вообще читал, на что ответил? Или просто увидел
>пару знакомых слов и тут же написал свое мнение о них?
>Перечитай еще раз, что там написано, и подумай, к чему ты
>приплел то, что какие-то внутренние локи Lustre одинаковые? Ну как, получилось?Не придумывай. Я лиш написал что ldlm extent lock - это другое название byte-ranged lock.
ldlm extent lock - защищает byte range в файле, туже функцию в pohmelfs выполняет byte-rage lock. Так кто не читает что пишет?
>
>
>Я хоть похмелфс и не знаю в деталях, но по крайней мере
>стараюсь адекватно судить о том, что вижу, а не пытаюсь облить
>грязью то, в чем даже не пробовал разобраться. Отличные в Люстре
>разработчики, за светом глаз не видят вообще ничего.Смешной ты ;) я лиш цитирую с сайта и спрашиваю, почему это считается что это быстро.
Спрашиваю как оно себя будет вести в разных ситуациях - мне говорят, что я обливаю грязью.
Неужели критика и указывание плохих мест - это уже обливание грязью?
что-то последнее время пошла мода на распределенные сетевые файловые системы...
пришло их время — низы уже хотят, верхи уже могут
>что-то последнее время пошла мода на распределенные сетевые файловые системы...Не мода, а необходимость =)
Поляков рулит!!! Осталось дрийверок для Windows придумать, афторизацию через SQL/passwd/RADIUS и SMB, CIFS, NFS можно фтопку ......
>Осталось дрийверок для Windows придумать, афторизацию через SQL/passwd/RADIUS и
>SMB, CIFS, NFS можно фтопку ......Мне кажется что кое-кто успеет поседеть в ожидании драйверка для виндовса...
>>Осталось дрийверок для Windows придумать, афторизацию через SQL/passwd/RADIUS и
>>SMB, CIFS, NFS можно фтопку ......
>
>Мне кажется что кое-кто успеет поседеть в ожидании драйверка для виндовса...
Интересное такое название ПохмельФС, что-бы это значило?! Тесты в каком состоянии проводились?
POHMELFS stands for Parallel Optimized Host Message Exchange Layered File System.
>POHMELFS stands for Parallel Optimized Host Message Exchange Layered File System.Такое только с бодуна в голову стукнет!
Я уже предполагаю, что пользоваться этой ОС будет очень сложно. Вот если бы сделали крайне простое монтирование и управление, простое и понятное расшаривание - тогда интересно. Если очередная поделка, имеющая супер мощную функциональность, но при этом надо долго париться чтобы это заработало - такая ФС не нужна.
>Я уже предполагаю, что пользоваться этой ОС будет очень сложно. Вот если
>бы сделали крайне простое монтирование и управление, простое и понятное расшаривание
>- тогда интересно. Если очередная поделка, имеющая супер мощную функциональность, но
>при этом надо долго париться чтобы это заработало - такая ФС
>не нужна.Ей пользоваться - проще не бывает, одна команда на конфигурацию и сам mount.
И в фаерволе всего одна дырка нужна, не то что NFS.
>Я уже предполагаю, что пользоваться этой ОС будет очень сложно. Вот если
>бы сделали крайне простое монтирование и управление, простое и понятное расшаривание
>- тогда интересно. Если очередная поделка, имеющая супер мощную функциональность, но
>при этом надо долго париться чтобы это заработало - такая ФС
>не нужна.Вы NFS используете ? 5 демонов, portmap rpc.statd rpc.idmapd rpc.mountd rpc.rquotad + 7 TCP портов + 7 udp портов - это по вашему просто ? + ещё kerberos ...
> Вы NFS используете ? 5 демонов, portmap rpc.statd rpc.idmapd rpc.mountd rpc.rquotad + 7 TCP портов + 7 udp портов - это по вашему просто ? + ещё kerberos ...В том то и дело, что если получится нечто вроде NFS, то мне такое не надо. Приходится порой пользоваться NFS, но я предпочитаю CIFS... Это смешно, но под Linux оказывается удобнее пользоваться CIFS. Надеюсь POHMELFS решит эту несправедливость. Ну и ребрендинг малость не помешает :)
> Ей пользоваться - проще не бывает, одна команда на конфигурацию и сам mount. И в фаерволе всего одна дырка нужна, не то что NFS.
Ясно, спасибо. Я уже начинаю любить POHMELFS :)
>Грег пообщел рекомендовать код POHMELFS для помещения в основное дерево исходных текстов Linux ядра 2.6.30.Мало кто знает но он сделал это ради лулзов, вполне возможно находять в состоянии похожем на название субжика.
>Мало кто знает но он сделал это ради лулзов, вполне возможно находять
>в состоянии похожем на название субжика.Just For Fun теперь зовётся "ради лулзов"?
всё течёт, всё изменяется...
а что значит "ради лулзов" ? просвятите отсталого... ради прибыли ? или что ?
>а что значит "ради лулзов" ? просвятите отсталого... ради прибыли ? или
>что ?Означает, что сам процесс создания доставил автору удовольствие, а не какие-то другие мотивы.
http://lurkmore.ru/Лулз
Если уж делать ради лулзов, то зачем останавливаться толькл на названии? Тогда уж надо все технические детали свести к алкогольной тематике.mount -t pohmelfs -o vodka,seledka,oguretz
>Если уж делать ради лулзов, то зачем останавливаться толькл на названии? Тогда
>уж надо все технические детали свести к алкогольной тематике.
>
>mount -t pohmelfs -o vodka,seledka,oguretzБуржуины не осилят...