Re: semantics of TRYEMULROOT

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Jan 02, 2011 at 07:24:33PM +0000, David Holland wrote:
> 
> (Anyhow, like I wrote in that PR, the only real way forward for
> onionfs is to try to figure out a self-consistent model for the
> semantics. If as I suspect that turns out to be impossible, the right
> way forward is to kill onionfs and replace it with several similar
> fses each with a clear set of semantics specialized for a particular
> set of purposes.)

I wrote [1] a layered fs (for SYSV, also ran on solaris, SMP) that 
would never copy files between layers (but would create directories
in the top layer).
This worked fine for many uses - we used it for source trees and
object files.
For edits it rather relied on the fact that editors (well vi anyway)
doesn't write the existing file ever - but does another open(..., O_CREAT)
and so would create a new file in the top layer.

This fs only really had to handle vnode lookup, almost all other ops were
just relayed to the original fs.
the VOP_OPEN() function on sysv could change the vnode (so only operations
valid on unopened vnodes) should have needed relaying, however the 'exec'
code diddn't expect the vnode to change (or didn't even call vop_open)
so that didn't work.

I'm not sure how good the locking was, but I made heavy use of the
vnode reference counts.
I suspect locking on netbsd is somewhat harder.

        David

[1] OK fixed from some badly broken code to something that stood a
chance of actually working!

-- 
David Laight: david%l8s.co.uk@localhost