Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 May 1999 10:48:37 -0500 (CDT)
From:      David Scheidt <dscheidt@enteract.com>
To:        Don Lewis <Don.Lewis@tsc.tdk.com>
Cc:        Graeme Tait <graeme@echidna.com>, freebsd-hackers@FreeBSD.ORG, info@boatbooks.com
Subject:   Re: File system gets too fragmented ???
Message-ID:  <Pine.NEB.3.96.990527100539.30440C-100000@shell-1.enteract.com>
In-Reply-To: <199905271432.HAA10749@salsa.gv.tsc.tdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96.990527100539.30440C-100000>