From mboxrd@z Thu Jan 1 00:00:00 1970 From: MARTINET Dominique Subject: Re: [RFC PATCH] First RFC version of a new cache=mmap model. Date: Tue, 03 Sep 2013 16:44:56 +0200 Message-ID: <5225F5E8.9020604@cea.fr> References: <1378217781-27942-1-git-send-email-dominique.martinet@cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: V9FS Developers , linux-fsdevel@vger.kernel.org To: Eric Van Hensbergen Return-path: Received: from oxalide-out.extra.cea.fr ([132.168.224.8]:60445 "EHLO oxalide-out.extra.cea.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756590Ab3ICPdI (ORCPT ); Tue, 3 Sep 2013 11:33:08 -0400 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r83EiupQ014346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Sep 2013 16:44:56 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r83Eiufl022347 for ; Tue, 3 Sep 2013 16:44:56 +0200 (envelope-from dominique.martinet@cea.fr) Received: from zia.cdc.esteban.ctsi (out.dam.intra.cea.fr [132.165.76.10]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with SMTP id r83Eiu2f010250 for ; Tue, 3 Sep 2013 16:44:56 +0200 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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