From owner-freebsd-hackers Sun Jun 3 9:47:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id B944C37B401 for ; Sun, 3 Jun 2001 09:47:50 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 3 Jun 2001 17:47:50 +0100 (BST) To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance In-Reply-To: Your message of "Sat, 02 Jun 2001 10:47:56 PDT." <200106021747.f52Hluf03989@earth.backplane.com> Date: Sun, 03 Jun 2001 17:47:49 +0100 From: Ian Dowse Message-ID: <200106031747.aa54373@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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