Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jun 2003 20:07:12 -0700
From:      David Schultz <das@FreeBSD.ORG>
To:        Mohammad Nayyer Zubair <mzubair@ic.sunysb.edu>
Cc:        freebsd-fs@FreeBSD.ORG
Subject:   Re: ideas about a unioning file system
Message-ID:  <20030620030712.GA85079@HAL9000.homeunix.com>
In-Reply-To: <Pine.SOL.4.56.0306191803340.16978@sparky.ic.sunysb.edu>
References:  <Pine.SOL.4.56.0306191803340.16978@sparky.ic.sunysb.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2003, Mohammad Nayyer Zubair wrote:
> 
> Hi.
> 
> We are currently designing a stackable, fan-out file system, similar in
> principle to the freebsd unionfs filesystem, at the Files and Storage
> Lab at Stony Brook University.
> 
> We intend to use the FiST (http://www1.cs.columbia.edu/~ezk/research/fist/) stackable templates.
> 
> 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?

Unionfs in FreeBSD has a number of implementation issues.  Many of
these stem out of locking problems and the fact that VFS layering
doesn't really work right in FreeBSD.  These are fixable details,
and perhaps FiST addresses some of these.

I think the cleanest way to do a union-like implementation is at
the block level, with writable (``snap-off'') snapshots.  This
approach avoids ugly situations where file or directory renames
require massive amounts of copying.

Writable snapshots also have very clean semantics from the point
of view of determining when a particular part of the upper layer
is disassociated from modifications that may occur in the lower
layer.  Specifically, after the snapshot is made, changes in the
lower layer are never reflected in the upper layer.  With unionfs,
by contrast, changes in the lower layer are reflected in the upper
layer, but only for files that haven't already been modified in
the upper layer.  This can result in inconsistencies across files.

On the other hand, in certain situations, the semantics offered by
unionfs can be very useful.  For example, an administrator could
upgrade the userland of multiple virtual machines based on
union-mounted filesystems while allowing local modifications to
persist.  So writable snapshots are not a drop-in replacement for
something more like unionfs.  Perhaps there are better
alternatives that I'm unaware of.  I've heard various mutterings
about views, but I don't know offhand how to interpret updatable
views outside of a relational database context...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030620030712.GA85079>