Looking for competent nullfs/umapfs/unionfs testers..

I cannot test all the weird edge-cases of the stacked filesystems
myself, so I need somebody to help test them for me.

Here's the deal as seen from my side:

1. It should not take more of my time to deal with the testers than it
   would to test the stuff myself.

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.

3. The tests should result in stuff going into the src/tools/regression
   framework so it can be reused in the future.

I'm looking for testers who:

    - can think out things to test and write scripts/programs that
      tests it.

    - will spend the time producing a minimal testcase for the failures
      they encounter.

If this sounds like you, just go right ahead and send me reports when
you find something which doesn't work.

The code I want you to test is in the p4 branch "phk_bufwork" if you
don't have access to perforce you can pull down a patch relative
to -current here:
	http://phk.freebsd.dk/patch/buf_work.patch

Poul-Henning

[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.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.