In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>
> I would further recommend a (dynamic) array of pointers at the first
> level as part of the summary structure. Any given array entry would
> either point to the second level array (the 512 byte allocations),
> be NULL (no second level array was necessary), or be (void *)-1 which
> would indicate that the second level array was reclaimed for other
> uses.
Nice idea, but I'm not sure I see the benefit of partially reclaiming
second-level arrays. Because it is a hash array, there isn't really
the concept of a working set; a directory that is `in use' will
rarely see many create/rename/delete operations on a small fixed
set of filenames. The lookup case is already cached elsewhere. I
think an all-or-nothing approach is likely to perform better and
be simpler to implement. Even the lazy allocation of second-level
arrays is unlikely to help a lot if the hash function does its job
well.
>
> If the zone allocator is used for the second level block allocations
> it shouldn't be a problem. You can (had better be able to!) put a mutex
> around zone frees in -current.
The locking issues I could see were more in the area of finding
inodes to free hashes from. A linked list of dirhash structures
could be maintained (protected by a mutex), but to free the dirhash
belonging to an inode, the inode would probably need to be locked.
That means dereferencing dirhash->dh_inode->i_vnode and trying to
lock it, so things become complex.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
