>>это подходит только в случае когда данные находятся на том же сервере
>>что и meta-data.
>>тогда вы перекладываете работу которую вам надо сделать - на плечи vfs.
>
>Именно, и чем больше я ее туда перекину, тем будет лучше.не выйдет. выполнение rpc при захваченых vfs локах будет весело.
>
>>Клиент обязан дождаться когда транзакция закончится, и новая транзакция не откроется до
>>тех пор пока не закончена старая? иначе мы имеем очень большое
>>окно между тем как мы закрыли транзакцию - и тем как
>>она реально закомичена на сервере.
>
>Зависит от флагов - можно сделать как sync, так и async транзакцию.
>
>Со второй мы можем потерять данные, т.к. никогда не узнаем, что она
>завершилась.
у люстры async - и данные она не теряет.
>
>
>Можно создать сколько угодно много транзакций и запустить их параллельно (на сервере
>они и будут обрабатываться параллельно), но мой опыт работы с ядерными
>сокетами показывает, что больше чем один поток размером в примерно 64к
>на 1гбит/с не нужно, т.к. сеть не тянет, поэтому есть одна
>кэшированная (в смысле не создается все время, а создана статически для
>сокета) транзакция на сокет, с которой идет бОльшая часть работы. Прием
>по отношению к ней асинхронен.
ех. кроме tcp/ip есть другие сети - где все не так печально.
есть TSO, есть network dma и тп.
>
>>клиент делает statfs - при этом другой клиент пишет (изменяет размер).
>>какой размер увидит первый клиент? будет ли повторно запрашиваться атрибуты файлов если
>>сделать 2 раза ls -l на каталоге с 100к файлов?
>
>Нет, они же кэшируются на клиенте. Если памяти достаточно и иноды не
>выкинули, в таком случае их придется перечитать. Статистика пока не синхронизируется.
ех.. а как же вы хотите писать? как может второй клиент узнать где для него конец файла что бы записать? он один раз сделал ls -l, получил атрибуты - второй клиент после этого записал в файл и сдвинул EOF.
после этого первый клиент проснулся и решил писать - он что потеряет данные первого?
