Re: Looking for competent nullfs/umapfs/unionfs testers..

Poul-Henning Kamp <phk_at_phk.freebsd.dk> schrieb:
>
> I cannot test all the weird edge-cases of the stacked filesystems
> myself, so I need somebody to help test them for me.

I am sufficiently interested in getting unionfs working to do some work.
Though, I cannot consider me competent in testing.

> 2. I'm not promising to fix all known problems, some of them may
>    be architecturally unfixable [1], I am merely trying to not break
>    them any further.

A comprehensive list of these problems could help making people
interested.

> [1]  In unionfs: a file is opened R/O and taken from the bottom
>      layer, and then mmap'ed.  Subsequently, the file is opened R/W
>      and mmaped by another process.  The R/W open copies the file
>      to the upper layer.  I have no idea if the two processes will
>      see a consistent mmap of the file, and if they don't I have
>      no idea how to fix it, short of always creating a vm_object
>      for the vnode thereby loosing the caching advantage of the
>      lower vnode (unless some VM system COW magic can be used ?).
>      In particular I don't intend to try to fix this problem.

If the semantics of a Unix file defines the behaviour in case of
plain files (I don't know. Perhaps the behaviour is defined as "undefined"
already.) it is essential that the semantics conforms to this definition.
Otherwise, it there is clearly no need to have the 2 mmaps consistent.
RW-opening of already open files should be restricted in some form.
How about return EOPNOTSUPP, if not overwritten by some flag?
The man page of flock(2) says that consistent behaviour is not guaranteed
by locking. I conclude that without locking it is neither. So the 
necessity for consistent behaviour has to be announced from the process
opening the file by using O_SHLOCK, IMHO.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257