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: Fri, 11 Nov 2005 12:38:08 -0500 Message-ID: <200511111738.jABHc8jw002938@sumu.lexma.ibm.com> References: <1131643942.9389.17.camel@kleikamp.austin.ibm.com> <20051110200741.GA23192@infradead.org> <200511102135.jAALZlfS016100@sumu.lexma.ibm.com> <1131676316.8804.93.camel@lade.trondhjem.org> <1131681856.8804.103.camel@lade.trondhjem.org> <200511111345.jABDjxvw020167@sumu.lexma.ibm.com> <1131722845.10610.7.camel@localhost.localdomain> Cc: Trond Myklebust , , nfsv4 , fsdevel Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:45975 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750956AbVKKRiM (ORCPT ); Fri, 11 Nov 2005 12:38:12 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jABHcC6p005909 for ; Fri, 11 Nov 2005 12:38: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 jABHdOVX068830 for ; Fri, 11 Nov 2005 10:39: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 jABHcBUZ021102 for ; Fri, 11 Nov 2005 10:38:12 -0700 To: "Charles P. Wright" In-reply-to: <1131722845.10610.7.camel@localhost.localdomain> (cwright@cs.sunysb.edu) Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >>>>> "Charles" == Charles P Wright writes: Charles> On Fri, 2005-11-11 at 08:45 -0500, John T. Kohl wrote: >> Other than i_mapping/f_mapping, I don't think it's possible right now >> for stacking file systems to handle the address_space operations in our >> layer *and* share the same pages with the backing-store, since the struct >> pages are attached to the address space via file->f_mapping. Charles> At Stony Brook, we've come across similar problems. It is relatively Charles> easy to double cache, but inefficient. It is also relatively easy to Charles> single-cache, but then you don't get to intercept any of these Charles> interesting operations. Getting both at once is tricky. We currently do single-caching, by passing on the mmap operation to the backing store (swapping in the backing store file for vma->vm_file). (We do the equivalent in our MVFS built for vnode kernels.) Swapping the vm file is mostly workable, but we do have to be a bit too knowledgable about the innards of file mapping and do some things to accomodate the actions taken after fop->mmap is called. However, it does mean that things like /proc//exe show the backing-store file name not the upper-level name. That screws up some programs like Java which use /proc/self/exe to find their environment, since our backing-store directory layout is nothing like the upper-level layout. -- John Kohl Senior Software Engineer - Rational Software - IBM Software Group Lexington, Massachusetts, USA jtk@us.ibm.com