From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: [RFC] Support for stackable file systems on top of nfs Date: Thu, 10 Nov 2005 16:40:24 -0500 Message-ID: <1131658825.8209.5.camel@localhost.localdomain> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <20051110200741.GA23192@infradead.org> <200511102135.jAALZlfS016100@sumu.lexma.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: nfsv4 , fsdevel Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:13745 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S932146AbVKJVkb (ORCPT ); Thu, 10 Nov 2005 16:40:31 -0500 To: "John T. Kohl" In-Reply-To: <200511102135.jAALZlfS016100@sumu.lexma.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-11-10 at 16:35 -0500, John T. Kohl wrote: > > On Thu, Nov 10, 2005 at 11:32:22AM -0600, Dave Kleikamp wrote: > >> The following patch allows stackable file systems, such as ClearCase's > >> mvfs, to run atop nfs. mvfs has it's own file and inode structures, but > >> points its inode->i_mapping to the lower file system's mapping. This > >> causes problems when nfs's address space operations try to extract the > >> open context from file->private_data. > >> > >> The patch adds a small overhead of checking the file structure to see if > >> it contains an inode that is not the mapping's host. > >> > >> I am curious if there are any other stackable file systems that could > >> benefit from this. > > Let me explain a bit more what's going on here. MVFS would like to do > the same thing that CODA does. In the file->mmap() operation, CODA and > MVFS want to set up paging operations to be handled by the backing store > inode. See for example fs/coda/file.c:coda_file_mmap(), it sets > coda_inode->i_mapping = host_inode->i_mapping. > > But this fails when host_inode is an NFS inode. NFS assumes > that when it gets paging operations, it can look at the file pointer > passed to the address_space_operations' readpage function, and that file > pointer will be for an open NFS file. If NFS is a backing store inode, > the file pointer is for the stacked file system's open file. > > CODA certainly won't work today with NFS host inodes and mapped files. > I'm not surprised nobody noticed, since that seems like a poor way to > use CODA. Using NFS backing store is a primary use case for ClearCase > MVFS, so we noticed. I think you'd notice it on other file systems as well. For instance, my experience is that GFS doesn't play nice w/ stackable file systems that try to stack on the a_ops. On the other hand, it's ok if it just passes all page cache operations directly down to the lower file system. OCFS2, on the other hand, seems to play better w/ stacking on the a_ops.