>то есть разговора о производительности метаданных не идет ?
>для решения вопросов о локах - у люстры свой lockd, это один
>из самых обольших ее кусков. Из чего вы сделали такой вывод о производительности метаданных?
>так же как и при журналировании данных.
Ога, а кто дожидется, что запись в журнал завершена :)
>tso - в сочетании с zero copy sockets - это network dma
>для бедных. указали большой буфер, а сетевуха сама порежет на пакеты
>и плюнет в получателя.
tso прозрачно для сокетного интерфейса - если поддерживается картой, то стек об этом позаботится и создат большуй skb, в противном случае побъет на mss/mtu.
>>Надеюсь, что вы не пишете такой код... Задайте тот же самый вопрос,
>>если у вас два потока, один делает lseek(), а второй просто
>>write(). И тоже самое будет с двумя клиентами pohmelfs.
>
>судя по вашим словам "статистика не сихнронизиуется" - первый клиент будет иметь
Статистика _пока_ не синхронизируется, это раз.
>i_size = size_old, от первого ls -l (выполнен stat), и будет
>писать ровно с этой позиции - оно закэшировано в его vfs
>стеке.
>
>второй клиент i_size уже обновил - и писать надо с другой позиции
>- но без когерентности meta-data - как первый клиент узнает
>что размер обновился? кто за него сделает этот lseek?
Вы разве не видите огромный race в этом случае для локального VFS и двух потоков?
Прямо один в один, только потоки локальные. Что будет, если один собрался делать write(), а второй lseek()?
Так банально _НЕЛЬЗЯ_ делать, если вы заботитесь о сохранности данных, т.к. другой поток может вызвать lseek() и переписать указатель, откуда надо делать write(). Для этого и изобрели pwrite() и остальных (собственно, они и используются в pohmelfs server).
Еще раз повторю, что pohmelfs не будет поддерживать синзхронизацию более строгую, чем локальный VFS.
