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:35:47 -0500 Message-ID: <200511102135.jAALZlfS016100@sumu.lexma.ibm.com> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <20051110200741.GA23192@infradead.org> Return-path: Received: from e3.ny.us.ibm.com ([32.97.182.143]:25250 "EHLO e3.ny.us.ibm.com") by vger.kernel.org with ESMTP id S932139AbVKJVfx (ORCPT ); Thu, 10 Nov 2005 16:35:53 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAALZnPN016065 for ; Thu, 10 Nov 2005 16:35:49 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAALZnkm114292 for ; Thu, 10 Nov 2005 16:35:49 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAALZm7M010033 for ; Thu, 10 Nov 2005 16:35:49 -0500 To: nfsv4 , fsdevel Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > 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. -- John Kohl Senior Software Engineer Rational Software IBM Software Group Lexington, Massachusetts, USA jtk@us.ibm.com The opinions expressed in this message do not reflect the views of my employer.