ideas about a unioning file system

[The Hermit Hacker]

I missed the original message, so excuse me, but am piggy backing on
Andrew's response :)

On Tue, 24 Jun 2003, Andrew Reilly wrote:

> Hi,
>
> On Fri, 2003-06-20 at 08:15, Mohammad Nayyer Zubair wrote:
> > Has anyone extensively used freebsd unionfs? From a system/network
> > administrator or from a kernel developer standpoint, what do you like
> > about it and what you dont like about it?
>
> I'm using unionfs thusly:
>
> # Device                Mountpoint      FStype  Options         Dump
> Pass#
> /dev/ad0s1a             /               ufs     rw              0
> 1
> /dev/vinum/mirror       /home           ufs     rw              0
> 2
> /dev/vinum/vinum0       /usr            ufs     rw,union        0
> 2
>
> (sorry about the wrappage, cut and pasted from /etc/fstab.)

neptune# df -t union | wc -l
      40
neptune# ssh jupiter df -t union | wc -l
      41
pluto# ssh pluto df -t union | wc -l
      40

we use it for two reasons: it *greatly* reduces the disk foot print of
running jail'd environments (we figure we save ~40Gig per server), and it
makes upgrading applications in ports alot easier when you only have to
upgrade the "base" jail, instead of each and every one ...

> > Out of the previous efforts at a unioning file system like the Sun's TFS,
> > 3DFS, Plan 9 and FreeBSD unionfs itself, which fs do you think came close
> > to an ideal unioning file system?
>
> What's wrong with the one that we have?

Alot of things under the covers ... but at the 'visible' layer, I can't
think of anything I'd expect it to do any differently ... there are alot
of bugs still in unionfs, that are slowly being addresses as ppl are able
to produce "good debug info" ...

There was a recent thread on -arch that should be checked, that talked
about alot of the "implementation deficiencies" in unionfs, but other then
stability issues (ie. memory leaks, vnode leaks, etc), what unionfs *does*
I've been most happy with ...