From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: The argument for fs assistance in handling archives (was: silent semantic changes with reiser4) Date: Thu, 2 Sep 2004 12:42:36 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: <20040826150202.GE5733@mail.shareable.org> <200408282314.i7SNErYv003270@localhost.localdomain> <20040901200806.GC31934@mail.shareable.org> <1094118362.4847.23.camel@localhost.localdomain> <20040902175034.GA18861@lst.de> <1094151873.16620.18.camel@polarbear.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Christoph Hellwig , Jamie Lokier , linux-fsdevel@vger.kernel.org Return-path: Received: from fw.osdl.org ([65.172.181.6]:14986 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S268370AbUIBTms (ORCPT ); Thu, 2 Sep 2004 15:42:48 -0400 To: "Charles P. Wright" In-Reply-To: <1094151873.16620.18.camel@polarbear.fsl.cs.sunysb.edu> List-Id: linux-fsdevel.vger.kernel.org On Thu, 2 Sep 2004, Charles P. Wright wrote: > > Stackable file systems are a good fit for doing things like this. They > layer on top of an existing directory and intercept all of the vfs_* > calls. You can do lots of neat things like encryption versioning, > compression, and more. Stackable filesystems are really hard, and ambiguous on where things go, and what happens when you remove an entry that hides another one. Sure, you can make up any amount of semantics, but the fact is, all the semantics _are_ going to be pretty arbitrary, and fairly complex. I'd frankly _much_ prefer not having stackable filesystems supported by the VFS layer. 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. Btw, this kind of non-VFS-supported filesystem would not necessarily have coherency guarantees: if you changed /usr or /usr/local directly (rather than through the stackable /mnt), you could confuse stackfs. Kind of the same way you can confuse a NFSv2 client by operating directly on the server (ie I'm not saying "confuse" in a "blow up the kernel" kind of way, but in a "would return -ESTALE or similar"). Linus