Looking for competent nullfs/umapfs/unionfs testers..
Poul-Henning Kamp
phk at phk.freebsd.dk
Thu Jan 27 02:44:59 PST 2005
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.
More information about the freebsd-current
mailing list