Re: unionfs 5.4

> I've found nullfs toooo slow in jail.

There seems to be a common consensus that nullfs is a bit of a tortoise.

Stab in the dark:
I haven't looked at this in great detail, but the very top of
nullfs_subr .c defines the size of a hashtables used for storing all
the null nodes into. It's only 16 buckets. That seems awfully under
provisioned to me: there might be tens of thousands of "underlying"
vnodes, giving a best-case scenario of thousands of iterations over
one of these buckets to find an upper "null" node. Even the hash
function seems pretty ropey...

unionfs has a similar hash table (32 buckets instead of 16, and
separate locks on each bucket) but it might not invoke the searches as
often: I'm not as familliar with its design.

If someone experiencing these issues could try rebuilding after changing

#define NNULLNODECACHE 16
to 
#define NNULLNODECACHE 1024

in null_subr.c (line 50 in my version, 1.45)

And just see if it makes much of a difference. If so, it might be
worth making more flexible. (Sizing proportionally to maxvnodes or
something, as UFS does, or replacing with a more scalable data
structure.)