>>не выйдет. выполнение rpc при захваченых vfs локах будет весело.
>
>Естественно, что что-то вытаскивается в сервер, плюс fcntl() локи уж очень медленные...
>то есть разговора о производительности метаданных не идет ?
для решения вопросов о локах - у люстры свой lockd, это один из самых обольших ее кусков.
>
>>у люстры async - и данные она не теряет.
>
>Т.е. она не дожидается подтверждения, что данные записаны, прежде, чем освободить страницы?
так же как и при журналировании данных.
>И как же это работает в случае отвала сервера? :)
есть много механизмов - replay журнала один из них.
>
>>ех. кроме tcp/ip есть другие сети - где все не так печально.
>
>Все любят только tcp/ip, даже поверх ib/iwarp/whatever.
>Хотя конечно можно и оптимизировать без них.
cray/hp/ibm - не любят tcp, и используют его только как service channel.
>[оверквотинг удален]
>>есть TSO, есть network dma и тп.
>
>Я могу получить доступ к IB-связанным машинам, но пока это не самая
>приоритетная задача, по понятным причинам незавершенности других вещей :)
>Под TSO вы наверное имели ввиду не tcp segmentation offload, а полную
>загрузку стека в карту - очень криво в подавляющем большинстве случаев,
>которые я видел (собствено, за это их и не берут в
>ядро и врядли когда не возьмут), а в остальных есть channel-like
>интерфейс, который можно легко прицепить к pohmelfs.
>
network dma - это в основном у IB и подобных карт, правда патчи для этого не принимаются в ядро - но позволяют передавать минуя стек. Это один из кусков патчей в люстре.
tso - в сочетании с zero copy sockets - это network dma для бедных. указали большой буфер, а сетевуха сама порежет на пакеты и плюнет в получателя.
>>ех.. а как же вы хотите писать? как может второй клиент узнать
>>где для него конец файла что бы записать? он один раз
>>сделал ls -l, получил атрибуты - второй клиент после этого записал
>>в файл и сдвинул EOF.
>>после этого первый клиент проснулся и решил писать - он что потеряет
>>данные первого?
>
>Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос,
>если у вас два потока, один делает lseek(), а второй просто
>write(). И тоже самое будет с двумя клиентами pohmelfs.
судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметь i_size = size_old, от первого ls -l (выполнен stat), и будет писать ровно с этой позиции - оно закэшировано в его vfs стеке.
второй клиент i_size уже обновил - и писать надо с другой позиции - но без когерентности meta-data - как первый клиент узнает что размер обновился? кто за него сделает этот lseek?
