From owner-freebsd-current Tue Apr 10 13:49:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id CB64737B42C for ; Tue, 10 Apr 2001 13:49:43 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f3AKmIT25835; Tue, 10 Apr 2001 16:48:18 -0400 (EDT) Date: Tue, 10 Apr 2001 16:48:16 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: Matt Dillon Cc: Brian Somers , Jason DiCioccio , "'current@freebsd.org'" Subject: Re: FW: Filesystem gets a huge performance boost In-Reply-To: <200104101824.f3AIOZ389340@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Matt Dillon wrote: > :> I'm not 100% convinced about the algorithm to avoid clusters filling > :> up with directory-only entries (it looks like a worst-case would fill > :> a cluster with 50% directories and 50% files leaving a bad layout when > :> the directories are populated further), but then the non-dirpref > :> scheme has some far worse worst-case scenarios ;-) > : > :Just to follow up on myself... it seems the dirpref stuff was > :committed to FreeBSD this morning :-] > : > :-- > :Brian > > Yup, Kirk committed it. I really like the changes -- in the old days > disk caches were tiny and directories were not well cached on top of that. > It made sense to try to keep directories close to their files. > > But today the proximity of a directory to its files is not really that > important. It is far more important for directories to have reasonable > proximity to each other not only to improve directory scans and lookups, > but also to improve caching. Especially for small directories. > Consider that small directories are typically contained in a single > fragment (1K). If directories are spread all over the disk, caching > is non-optimal. But if they are relatively close to each other then > both our VM cache (if vfs.vmiodirenable is set to 1) and the hard > drive's internal cache become extremely effective. With the added Why VMIO dir works better if directories are placed close to each other? I think it only makes the cache data of an individual directory stay in the memory longer. Is there a way to measure the effectiveness of the disk drive's cache? -Zhihui > effectiveness of the caches, seeking should wind up being > significantly reduced even for things like 'tar'. Large directories > also benefit, I think. > > From looking at the code, I don't think fragmentation will be an issue. > Or, to be more specific, I don't think the fact that files may not wind > up in the same cylinder group as their directory entry is an issue. > Either you have a huge number of directories being accessed and need > the locality of reference within the directory space even if it costs > some additional seeking to access underlying files, or you don't and > the active directories all wind up being cached, removing any additional > seeking from the equation entirely. > > -Matt > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message