From owner-freebsd-current  Fri May 17 14:18:32 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id OAA20434
          for current-outgoing; Fri, 17 May 1996 14:18:32 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA20418;
          Fri, 17 May 1996 14:18:17 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA20703; Fri, 17 May 1996 14:15:07 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199605172115.OAA20703@phaeton.artisoft.com>
Subject: Re: mount_union
To: wollman@lcs.mit.edu (Garrett Wollman)
Date: Fri, 17 May 1996 14:15:07 -0700 (MST)
Cc: hsu@freefall.freebsd.org, current@freefall.freebsd.org
In-Reply-To: <9605171921.AA06622@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at May 17, 96 03:21:07 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> NB: `union mount' != `unionfs'.  Unfortunately, even the 4.4 book
> preserves this linguistic inaccuracy.  Support for `union mounts'
> (i.e., `MNT_UNION') has been present for a long time, and so far as I
> am aware works just fine (at least, I have not seen any crashes which
> can be traced to this code; I haven't used it in a while and it might
> be broken now).  (If anyone thinks it doesn't work, I'd like to hear
> about it.)  This is a completely different animal from `unionfs'
> (MOUNT_UNION) which really ought to be called something like
> `translucentfs' but that would be too long.  Different purposes,
> different mechanism, sometimes similar results.

I think it's broken for union mounting of RO and RW media since the
enformcement of RO was moved into the FS proper.

For what it's worth, I think the enforcement *belongs* in the FS
proper instead of in the top level code because stacking means
that it can only be safely enforced in the terminal FS (the FS
with the RO mount).

My thinking this doesn't make it not get occasional "write of read only..."
errors, though.

I was waiting until after the 4.4-Lite2 integration is completed to
fix this and the other FS layers.  I also have a quota FS layer and
some vn_lock changes on top of the lockmgr() functional abstraction
from Lite2, but they have to wait for Lite2 as well.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.