Date: Fri, 17 May 1996 14:15:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett Wollman) Cc: hsu@freefall.freebsd.org, current@freefall.freebsd.org Subject: Re: mount_union Message-ID: <199605172115.OAA20703@phaeton.artisoft.com> In-Reply-To: <9605171921.AA06622@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at May 17, 96 03:21:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605172115.OAA20703>