DragonFly kernel List (threaded) for 2006-06
Re: ZFS (fwd)
:As far as I can tell, it probably won't happen until the userland VFS
:work, which won't happen until the MP work, which was going along
:great but with no commits for a while now (not necessarily a bad sign,
:just means we can't tell what's happening). Meanwhile, you have
:OpenSolaris, which should be comparable in stability and performance
:to DragonFly, and can utilize pkgsrc :)
: -- Dmitri Nikulin
Yah, its a chicken and egg problem. The key issue with the MP work
is to get it down into the VFS interface (it isn't at the moment).
Then userland VFS can proceed.
At the moment I'm stuck trying to figure out the best way to make the
namecache MP safe. I'm trying to avoid FreeBSD's master mutex approach.
Nor do I want to have a per-namecache-record spinlock since this would
drastically reduce performance on long paths.
I think the best solution might be to have a 'zone' spinlock for the
namecache. The idea is that the namecache records would have a pointer
to a spinlock structure which might be shared across multiple records.
Initially the 'zone' would be the entire namecache. When a conflict
occurs the namecache would determine if it would be beneficial to split
the namecache's spinlock.
For example, lets say we were running a mail system with multiple
mail queues. queue, queue/a, queue/b, and queue/c. The entire hierarchy
would start out sharing a spinlock. As the load causes spinlock conflicts
the namecache would break-out the mail queue directories, giving them
their own spinlock.
One approach to this would be to have a fixed pool of spinlocks, say
128. Theoretically one does not need any more then the maximum amount
of parallelism one desires in the namecache. Spinlocks from the pool
would be assigned to namecache records and the system would choose a
'random' spinlock from the pool when it decides it needs to reassign
Because reassignment is a dynamic operation, a fixed pool gives us
the ability to maintain consistency during the reassignment by
guarenteeing that the spinlock itself would not be destroyed by
creation/deletion operations in the namecache.
In anycase, I'm starting to shift into release mode. I will pick up
the namecache work after we release in mid-July. I've made a considerable
amount of progress with the MP work just locking up the file descriptors
and file pointers, so its good to take a break and make sure that all
that work is solid before doing another push.