Date: Sun, 03 Jun 2001 17:47:49 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance Message-ID: <200106031747.aa54373@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sat, 02 Jun 2001 10:47:56 PDT." <200106021747.f52Hluf03989@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200106021747.f52Hluf03989@earth.backplane.com>, 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200106031747.aa54373>