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:36:46 -0500 Message-ID: <1131658607.8209.2.camel@localhost.localdomain> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <1131657893.8816.19.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Dave Kleikamp , nfsv4 , fsdevel Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:42928 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S932122AbVKJVhC (ORCPT ); Thu, 10 Nov 2005 16:37:02 -0500 To: Trond Myklebust In-Reply-To: <1131657893.8816.19.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-11-10 at 16:24 -0500, Trond Myklebust wrote: > On Thu, 2005-11-10 at 11:32 -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. > > NACK > > This is a fundamentally flawed approach. The nfs_find_open_context() is > designed for the mmap() case were you have a valid vm_area_struct, that > has a "struct file" with a valid NFS open context attached to it. > Existence of the file is guaranteed, but the readpage() and writepage() > interfaces don't actually pass the struct file down to the filesystem. > > This is clearly not the case here. > > If you want to make mvfs work correctly with NFS, then have it set up a > valid NFS struct file, and use that file with the NFS functions. > Anything else is borken. from my experiences with stackable file systems, I'm not sure the above is totally correct. i.e. vm_area_structs only around while a process is in use. Once a process exits, the file and vm_area_struct go away. now imagine if you do a mmap shared write, don't sync and just exit the program. Some time later the kernel will kick in, call writepage() and write the page to disk, but your above "guarantees" are no longer around.