From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John T. Kohl" Subject: Re: [RFC] Support for stackable file systems on top of nfs Date: Thu, 10 Nov 2005 16:57:06 -0500 Message-ID: <200511102157.jAALv6mk020461@sumu.lexma.ibm.com> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <20051110200741.GA23192@infradead.org> <200511102135.jAALZlfS016100@sumu.lexma.ibm.com> <1131658825.8209.5.camel@localhost.localdomain> Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:26525 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S932116AbVKJV5N (ORCPT ); Thu, 10 Nov 2005 16:57:13 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAALvCtr009880 for ; Thu, 10 Nov 2005 16:57:12 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAALwOlu064478 for ; Thu, 10 Nov 2005 14:58:24 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAALvBww021449 for ; Thu, 10 Nov 2005 14:57:12 -0700 To: nfsv4 , fsdevel In-reply-to: <1131658825.8209.5.camel@localhost.localdomain> (message from Shaya Potter on Thu, 10 Nov 2005 16:40:24) Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >>>>> "Shaya" == Shaya Potter writes: >>>>>> > On Thu, Nov 10, 2005 at 11:32:22AM -0600, Dave Kleikamp wrote: Dave>> The following patch allows stackable file systems, such as ClearCase's Dave>> mvfs, to run atop nfs. mvfs has it's own file and inode structures, but Dave>> points its inode->i_mapping to the lower file system's mapping. This Dave>> causes problems when nfs's address space operations try to extract the Dave>> open context from file->private_data. Dave>> Dave>> The patch adds a small overhead of checking the file structure to see if Dave>> it contains an inode that is not the mapping's host. Dave>> Dave>> I am curious if there are any other stackable file systems that could Dave>> benefit from this. John>> Let me explain a bit more what's going on here. MVFS would like to do John>> the same thing that CODA does. In the file->mmap() operation, CODA and John>> MVFS want to set up paging operations to be handled by the backing store John>> inode. See for example fs/coda/file.c:coda_file_mmap(), it sets John>> coda_inode-> i_mapping = host_inode->i_mapping. John>> John>> But this fails when host_inode is an NFS inode. NFS assumes John>> that when it gets paging operations, it can look at the file pointer John>> passed to the address_space_operations' readpage function, and that file John>> pointer will be for an open NFS file. If NFS is a backing store inode, John>> the file pointer is for the stacked file system's open file. John>> John>> CODA certainly won't work today with NFS host inodes and mapped files. John>> I'm not surprised nobody noticed, since that seems like a poor way to John>> use CODA. Using NFS backing store is a primary use case for ClearCase John>> MVFS, so we noticed. Shaya> I think you'd notice it on other file systems as well. For instance, my Shaya> experience is that GFS doesn't play nice w/ stackable file systems that Shaya> try to stack on the a_ops. On the other hand, it's ok if it just passes Shaya> all page cache operations directly down to the lower file system. Shaya> OCFS2, on the other hand, seems to play better w/ stacking on the a_ops. Hmm, so thinking about this more, I think the minimal patch would only change how the file structure is found for the address space operations, and leave the other ones alone. (And FYI, yes MVFS does have a (struct file *) open on the backing store inode, and uses it for non-mapping-related calls.) -- John Kohl Senior Software Engineer - Rational Software - IBM Software Group Lexington, Massachusetts, USA jtk@us.ibm.com