>>причем тут lseek?
>
>При том, что если два потока не синхронизированы, запись может происходить вообще
>в любое место файла. А с учетом того, что обновление 64битной
>переменной не атомарно (f_pos) на 32битной архитектуре, то при запуске этого
>приложения например в gdb (или при ptrace'инге) там может быть значение
>наполовину их одного потока, а наполовину из другого. для этого делаются блокировки.
>
>>Пишется буфер, позиция берется из f_pos, которая на момент open(,O_APPEND) берется из
>>i_size - все согластно POSIX.
>
>И только в этом случае f_pos устанавливается под i_mutex'ом.
или под dlm локингом.
>
>Это я к тому, что вы в любом случае должны (кроме как
>для O_APPEND) синхронизировать запись в файл между двумя потоками, и это
>не задача VFS или файловой системы следить за атомарностью записи.
ну ну.. у каждого свое виденье - лиш бы это не приводило к data corruption :)
>[оверквотинг удален]
>транзакции (там есть open intent, где сейчас передается только O_RDWR/O_RDONLY). Нужно
>поэкспериментировать.
>
>>хотел бы я посмотреть на rpc трафик в этом случае. ну да
>>лана.
>
>Вы показываете случай, в котором все сетевые файловые системы будут иметь серьезную
>нагрузку системных сообщений, при этом делаете акцент, что в pohmelfs будет
>большое их количество. Надо полагать, у вас есть какая-то причина быть
>необъективным :)
я лиш перевернул пример который был изначально дан для люстры. За одно показал к чему приводит нежелание синхронизировать meta-data между нодами.
>
>Кстати, механизм когерентности кэшей выполняется не как RPC, сервер сам рассылает сообщения
>об обновлениях/инвалидации.
RPC - remote procedure call. любое сообщение по которому получатель должен выполнить некоторое действие - во всяком случае в обычном контексте.
