>
>>Остальные тесты - для случая одного клиента. Что этим хотелось померять?
>>Нету не 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 - это одно и тоже.