[lkml]   [2004]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: unionfs
Your "what are the semantics?" arguments are mysterious to me, Horst.  I
don't know that unionfs is a good idea, but there are trivial solutions
to the problems you suggest. The fact that a facility can be used to
create untenable situations does not mean that the facility is useless.

On Mon, Mar 15, 2004 at 03:22:41PM -0400, Horst von Brand wrote:
> =?iso-8859-1?Q?J=F6rn?= Engel <> said:
> > On Mon, 15 March 2004 22:35:20 +0800, Ian Kent wrote:
> > > I don't understand the requirement properly. Sorry.
> > Depends on who you ask, but imo it boils down to this:
> > - Use one filesystem as backing store, usually ro.
> > - Have another filesystem on top for extra functionality, usually rw
> > access.
> >
> > Famous example is a rw-CDROM, where writes go to hard drive and
> > unchanged data is read from CDROM. But it makes sense for other
> > things as well.
> And what if the underlying filesystem is RW too?

Only the topmost layer of a "union stack" should be RW. If you manage
to write to an underlying FS, it is akin to writing to the block device
underlying a normal FS -- the behavior is undefined.

> What should happen if you unite several (>= 3) filesystems? What if
> some are RO, others RW?

Given that only the topmost is RW, it Just Works.

> What do you do if a file shows up several times, each different?

The topmost entry wins.

> Assuming one RW on top of a RO only now: What should happen when a
> file/directory is missing from the top? If the bottom one "shows through",
> you can't delete anything; if it doesn't, you win nothing (because you will
> have to keep a complete copy RW on top).

If a directory entry is missing, the next lower layer is consulted.
Delete is implemented with "white-out" directory entries -- a directory
entry in the topmost FS which has special meaning, "return -ENOENT
immediately without consulting FSs underlying me".

> IIRC, this has been discussed a couple of times before, and the consensus
> each time was that it isn't /that hard/ to do, it is /hard or impossible/
> to find a sensible, simple semantics for this. The idea was then dropped...

The semantics of BSD unionfs are fairly well-defined and useful in at
least some circumstances.


J. S. Pendry and M. K. McKusick. Union mounts in 4.4BSD-Lite.
In Proceedings of the USENIX Technical Conference on UNIX and Advanced
Computing Systems, pages 25­33, December 1995.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.126 / U:12.432 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site