Re: process killed: text file modification

Konstantin Belousov wrote:
[stuff snipped]
> By 'impossible' I mean some arbitrary combination of bytes which were
> written by many means to the file at arbitrary moments.  In other words,
> the file content, or even a single page/block content is not atomic
> WRT the client updates.
Yes. For multiple processes writing the same file, I'd agree that's going to happen
unless the processes use advisoty byte range locking to order the updates.

And, I'm pretty sure a process that does both write(2) syscalls on a file and
modifies pages of it that are mmap()'d will produce "interesting" results as you
describe.
[stuff snipped]
> Or, what seems more likely to me, the code was written on a system where
> buffer cache and page queues are not coherent.
>
> Anyway, my position is that nfs VOP_PUTPAGES() should do write through
> buffer cache, not issuing the direct rpc call with the pages as source.
Hmm. Interesting idea. Since a "struct buf" can only refer to contiguous bytes,
I suspect each page might end up as a separate "struct buf", at least until some
clustering algorithm succeeded in merging them.

I would agree that it would be nice to change VOP_PUTPAGES(), since it currently
results in a lot of 4K writes (with FILE_SYNC I think?) and this is normally slow/inefficient
for the server. (It would be interesting to try your suggestion above and see if the
pages would cluster into larger writes. Also, the "struct buf" code knows how to do
UNSTABLE writes followed by a Commit.)
--> I am currently working on a pNFS server (which is coming along fairly well), so
      I have no idea if/when I might get around to trying to do this.

> Then your patch would need an update with the mentioned call to ncl_flush().
Yes.

rick