Re: The argument for fs assistance in handling archives (was: silent semantic changes with reiser4)

Linus Torvalds
2004-09-02T19:42:48Z

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