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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
