Re: [RFC PATCH] First RFC version of a new cache=mmap model.

[MARTINET Dominique <dominique.martinet@cea.fr>]

On 09/03/13 16:24, Eric Van Hensbergen wrote:
> Interesting, do me a favor and cross-post to at least linux-fsdevel --
> there have been some strong objections from the rest of the community on
> similar approaches in the past, and I'd rather we encounter them earlier
> rather than when I try to push the patch upstream.  The lack of
> consistency is pretty nasty, we'll need a big disclaimer in the
> documentation if we decide to take it forward.  You may also want to
> cross-check some of my earlier efforts (back in 2.6.14 timeframe IIRC)
> if you haven't already.  I had some hackery to try and force things
> through sooner.

Right, sorry about this, reposted it to everyone right now.

> FWIW, the right approach is probably to try and go for some more
> intelligent caching mechanism based on revokable leases so that the
> server can force a flush on a client if necessary -- but I understand
> that's a pretty big nut to crack and if this solves for your use case
> perhaps its the right start.

I tried to enable cached read/writes to keep the original behaviour, but 
it pretty quickly turns back into a cache=loose without metadata 
behaviour and I wanted to avoid this - the less cached the better as far 
as I'm concerned.

I'm also working on a 9P server (nfs-ganesha, 
https://github.com/nfs-ganesha/nfs-ganesha ), so breaking the server 
definitely isn't out of question.
Something based on lock/getlock might be possible but I don't think 
there is anything in the protocol that would make them revokable, 
especially since every message originates from the client...
If anything, I'd rather check before reading or writing if we have dirty 
pages to avoid inconsistencies with other filesystems.

-- 
Dominique