>>>Смешно. А тот тест, который ты цитируешь - он какое-то отношение к
>>>этому имеет? :)
>>
>>для 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. Так кто не читает что пишет?

>
>
>Я хоть похмелфс и не знаю в деталях, но по крайней мере
>стараюсь адекватно судить о том, что вижу, а не пытаюсь облить
>грязью то, в чем даже не пробовал разобраться. Отличные в Люстре
>разработчики, за светом глаз не видят вообще ничего.

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