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 17:27:36 -0500 Message-ID: <1131661656.8209.11.camel@localhost.localdomain> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <1131657893.8816.19.camel@lade.trondhjem.org> <1131658607.8209.2.camel@localhost.localdomain> <1131661094.8804.17.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: fsdevel , nfsv4 , Dave Kleikamp Return-path: To: Trond Myklebust In-Reply-To: <1131661094.8804.17.camel@lade.trondhjem.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-11-10 at 17:18 -0500, Trond Myklebust wrote: > On Thu, 2005-11-10 at 16:36 -0500, Shaya Potter wrote: > > 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. > > ...calling file->f_ops->release() in the process. Guess what happens > there? from my experience, writepage is called signficantly after a process is gone. I've seen this via instrumenting writepage() in using stackable file systems and a simple program that maps a file, modifies it, and then exits. the kernel hit the writepage() function 30 seconds or so after the process existed. ext2_release_file just does a ext2_discard_prealloc, which has nothing to do with written data. In looking at nfs, nfs_file_release does write out the data by calling filemap_fdatawrite(), but it seems somewhat unique in that regard, but I guess we are talking about NFS here. :)