From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erez Zadok Subject: Re: The argument for fs assistance in handling archives (was: silent semantic changes with reiser4) Date: Thu, 2 Sep 2004 16:30:11 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <200409022030.i82KUBRN017332@agora.fsl.cs.sunysb.edu> References: Cc: "Charles P. Wright" , linux-fsdevel@vger.kernel.org Return-path: Received: from filer.fsl.cs.sunysb.edu ([130.245.126.2]:6075 "EHLO filer.fsl.cs.sunysb.edu") by vger.kernel.org with ESMTP id S269036AbUIBUaU (ORCPT ); Thu, 2 Sep 2004 16:30:20 -0400 To: Linus Torvalds In-reply-to: Your message of "Thu, 02 Sep 2004 12:42:36 PDT." List-Id: linux-fsdevel.vger.kernel.org In message , Linus Torvalds writes: [...] > That said, I think you can make stackable filesystems as a _separate_ > filesystem (aka "view" or whatever), which is slightly different from > supporting them in the VFS layer itself: make it a filesystem of its own, > rather than supporting it on a VFS layer as a merge of two different > filesystems. That way you still have totally arbitrary semantics for how > the stacking works, but at least it's not codified by the VFS layer - it's > codified by nothing more special than one more random filesystem > implementation, and you could in fact have _different_ semantics depending > on what the user wants. > > Same end result, different "mindset". I think this is what FiST actually > does, but I could be wrong. > > What's the difference? If the VFS layer supports it (like the VFS supports > regular "opaque" overmounting), you'd just do > > mount -o stack /dir /otherdir > > the same way you do "bind" mounts. In contrast, if you do it as a > third-party "view" filesystem, it would be more like > > mount -t stackfs -o under=/usr,over=/usr/local /mnt > > where /usr and /usr/local would be the same old underlying filesystems, > and you'd see a totally new filesystem at /mnt. [...] Yes, that's exactly how our stacked f/s's work: not touching or modifying VFS or lower f/s's, but of course we use the VFS the way other f/s's use it (calling vfs_* functions and such). Each of our stackable f/s is a separate f/s in its own. And they're a nice way to augment the functionality of any other f/s w/o the hassles of changing a lower-level f/s format or the VFS. We recently did an example f/s that adds EA+ACL functionality on top of anything else, using the lower file system's EA/ACL support if it's there, and for f/s's that don't support EA/ACL natively, we support the ea/acl f/s calls and store the actual ea/acl data in a small database. We've even demonstrated that it worked on v/fat (yes, we know, vfat+ACLs is an an oxymoron :-) We also found out over the years that our stackable file systems are an interesting way to prototype features that might eventually move up to the VFS itself; this is b/c each stacked f/s has to appear to the lower f/s as the VFS itself, essentially emulating most of the VFS's functionality while at the same time appearing to the VFS as a lower-level f/s. It's not easy maintaining this split personality. :-) Erez.