>>Смешно. А тот тест, который ты цитируешь - он какое-то отношение к
>>этому имеет? :)
>
>для 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 одинаковые? Ну как, получилось?
Я хоть похмелфс и не знаю в деталях, но по крайней мере стараюсь адекватно судить о том, что вижу, а не пытаюсь облить грязью то, в чем даже не пробовал разобраться. Отличные в Люстре разработчики, за светом глаз не видят вообще ничего.
