From owner-freebsd-hackers Thu May 27 8:48:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caffeine.internal.enteract.com (caffeine.internal.enteract.com [207.229.129.24]) by hub.freebsd.org (Postfix) with SMTP id 9AE3214CDE for ; Thu, 27 May 1999 08:48:39 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 17343 invoked from network); 27 May 1999 15:48:38 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by caffeine.internal.enteract.com with SMTP; 27 May 1999 15:48:38 -0000 Received: from localhost (dscheidt@localhost) by shell-1.enteract.com (8.9.3/8.9.2) with SMTP id KAA30870; Thu, 27 May 1999 10:48:37 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-1.enteract.com: dscheidt owned process doing -bs Date: Thu, 27 May 1999 10:48:37 -0500 (CDT) From: David Scheidt To: Don Lewis Cc: Graeme Tait , freebsd-hackers@FreeBSD.ORG, info@boatbooks.com Subject: Re: File system gets too fragmented ??? In-Reply-To: <199905271432.HAA10749@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 May 1999, Don Lewis wrote: > On May 26, 6:59pm, Graeme Tait wrote: > } The filesystem is built with 4096 byte blocks, 512 byte fragments, and > } 2048 bytes/inode, and is mounted 'async noatime'. > > If a file shrinks by one fragment, it'll most likely leave a one > fragment gap in the block that can't be reused by another (new) file, > since the the minimum file size is two fragments. You could easily > get a 12.5% wasteage just from that. This is just shockingly nasty disk usage. I am unable to think of anything much worse, except more of this, with files that change all the time. > > It might help somewhat if a file that grows by a fragment can allocate > the free fragment immediately preceeding it instead of being relocated > to a fresh block. I don't know if FFS does this or not. FFS doesn't do this, and I don't think it could. What I think I would do if I had to deal with something this evil, is go to a 2048 fragment size. Most files will fit in one frag, so the the reallocation problem should be fixed. There will be 1536 blocks wasted for the largest of the small files. Not knowing the distribution of the file sizes, I can't make judgements about what the space wastage will add up to. However, space you can't allocate might as well not be there. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message