From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: v9fs writepage Date: Sat, 30 Apr 2005 13:47:35 -0500 Message-ID: References: <20050430183653.GE13052@parcelfarce.linux.theplanet.co.uk> Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Miklos Szeredi , v9fs-developer@lists.sourceforge.net, kernel-mentors@selenic.com, linux-fsdevel@vger.kernel.org, hch@infradead.org Return-path: Received: from rproxy.gmail.com ([64.233.170.195]:21840 "EHLO rproxy.gmail.com") by vger.kernel.org with ESMTP id S261337AbVD3Srg convert rfc822-to-8bit (ORCPT ); Sat, 30 Apr 2005 14:47:36 -0400 Received: by rproxy.gmail.com with SMTP id j1so698409rnf for ; Sat, 30 Apr 2005 11:47:36 -0700 (PDT) To: Al Viro In-Reply-To: <20050430183653.GE13052@parcelfarce.linux.theplanet.co.uk> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 4/30/05, Al Viro wrote: > On Sat, Apr 30, 2005 at 01:10:39PM -0500, Eric Van Hensbergen wrote: > > > It would seem a relaxed check in my v9fs_fid_locate would provide the > > same service as keeping open files in the inode. We had looked at > > doing something similar, but I hated the idea of having to keep the > > extra book-keeping if there was another path (particularly since we > > are already cacheing fids in dentries). > > a) 9P server is entirely within its rights to serve different contents > depending on the implied uid and even on phase of moon during the processing > of auth. So client-side file contents cache is not kosher. > Yes. I agree. I actually explicitly took all the cacheing behavior out of v9fs when I started getting involved a year ago. I only put the address_space operations back in recently in order to support mmap (which isn't supported at all under Plan 9). Would you rather I remove the vfs_addr.c support in order to stay more Plan 9 consistent? I figured I'd have a better chance of getting LKML acceptance by providing as many "linux semantics" as I could -- specifically we really wanted to pass fsx. > > Putting the information about caching into 9P would be interesting, but > that doesn't belong here - such stuff should be taken to Plan 9 maillist. > There is some precident for this in the cfs(4) file system under Plan 9 which providing something similar to the new Linux CacheFS for non-synthetic file systems (a unofficial rule of thumb was that anything that had a zero modification time was most likely synthetic and therefore unsuitable to cache). My plan has been to start by integrating this sort of layer on-top of the existing v9fs base and then do what I can to remove any performance penalty from implementing it as a stackable layer. I was also planning on talking to the linux CacheFS guys to see if their stuff would be suitable for this application. It's on the roadmap, but was planning to start after we get the inital core accepted to the kernel (trying to keep things as simple as possible). Its very likely we could just provide all mmap support within the cache layer. -eric