Date: Fri, 24 Jan 2003 19:40:50 -0500 From: Bill Moran <wmoran@potentialtech.com> To: Kevin_Stevens@pursued-with.net Cc: freebsd-questions@freebsd.org Subject: Re: Filesystem tuning parameters Message-ID: <3E31DD12.10601@potentialtech.com> References: <20030124160148.R12356@babelfish.pursued-with.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Stevens wrote:
> Also, why is "up to a factor of three in throughput" lost over the 10%
> setting? Is that another allusion to space optimization going into
> effect, or is there something else happening? I guess I don't understand
> the ramifications of the minfree setting. Any suggestions or references?
See
/usr/share/doc/papers/diskperf.ascii.gz
on your system. This is the authoritative resource as to why those settings
are they way they are.
The short answer is: the time/space/8% thing is a function of the way UFS
actually operates under real-world circumstances.
Notice how you never have to defrag a UFS partition (unlike a FAT or NTFS
partition). That's because the UFS code constantly optimizes where it
writes data as it's doing it, so data is _always_ written to logical places
such that the UFS code can quickly retrieve it when the time comes. The
downside to this ability is that the UFS code needs a certain amount of
free space to write this efficiently. When you reduce the amount of free
space below 8%, the space algorithm tries to allocate blocks in an efficient
manner and fails, writing data in a manner that has reads jumping all over
the place. Thus there is the space algorithm that kicks in when free space
is scarce. It takes longer to figure out where to write file data to, in
order to keep the filesystem orderly (so reads are still fast).
So ... it's like this:
1) If you really want to fill your drive up past 90%, understand that UFS
simply isn't designed to do that efficiently.
2) If you change the minfree setting, understand that writes are going to
take longer so the reads will stay fast.
3) If you tweak it beyond that, understand that you're throwing away a
considerable amount of research that others have done on UFS performance.
(read the article above first, so you know what you're doing)
4) If you bought a 120G drive because you have 119.5G of data to store, I
think you made a mistake and should either return it for a bigger drive
or accept the performance hit.
Furthermore, understand that _every_ filesystem I've ever worked with has this
problem. FAT & NTFS simply don't offer a way to work around it. Windows doesn't
have multiple block allocation methods, so when your FAT/NTFS drive gets very
full, read & write performance sucks. Ever try to defrag a FAT/NTFS drive that
was 90%+ full? Most defrag programs won't even try, they'll just tell you to
free up some space first.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E31DD12.10601>