Re: [PATCH] zerocopy NFS updated

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

David S. Miller wrote:
>    I'm not advocating more locking in read() -- there's no need, and it is
>    quite important that it is fast!  But I would very much appreciate an
>    understanding of the rules that relate reading, writing and truncating
>    processes.  How much ordering & atomicity can I depend on?  Anything at all?
> 
> Basically none it appears :-)
> 
> If you need to depend upon a consistent snapshot of what some other
> thread writes into a file, you must have some locking protocol to use
> to synchronize with that other thread.

Darn, I was hoping to avoid system calls.
Perhaps it's good fortune that futexes just arrived :-)

In some ways, it seems entirely reasonable for truncate() to behave as
if it were writing zeros.  That is, after all, what you see there if the
file is expanded later with a hole.

I wonder if it is reasonable to depend on that: -- i.e. I'll only ever
see zeros, not say random bytes, or ones or something.  I'm sure that's
so with the current kernel, and probably all of them ever (except for
bugs) but I wonder whether it's ok to rely on that.

-- Jamie