Scott <[EMAIL PROTECTED]> wrote:
> Hi,
> As a newbie to FreeBSD, I may be way off base, but it seems 
> very logical to me that the size of your drive or partition 
> would make a difference on at what percentage full one would 
> start to notice problems.
> In terms of megs/gigs 80% of 120 gigs still has a lot of 
> work space left. 80% of 4 gigs is not much. I would think 
> with a larger drive/partition, one could run at a higher 
> percentage before trouble started.

Logical or not, you're wrong.

The point is how hard the FFS algorithms have to search to find
a spot on the disk to put things, and how accessible that spot
is the next time that data is needed to be read.  While 10% of
120G seems like a lot of space, it's still only 10%.  Imagine a
parking lot with only 10% free spots.  If the lot has 1000 spots,
how long do you drive around before you find a _good_ spot?  If
it has a total of 100 spots, how long does it take to find a
_good_ spot?  The analogy isn't perfect, but the point is the
perceived improvement at having a higher number of free spaces
is offset by other factors, and the rule of 90% free stands
no matter what size the drive.

Newer drives with bigger caches, higher rotational speeds and
lower seek times are much more likely to change this percentage
than the physical size of the drive.

> It makes sense to me anyway :)
> Scott
>      | It is mentioned as a recommendation.  It
>      | is not an absolute. Do a little searching
>      | and you will probably find some
>      | references. We have some that run in to
>      | the 90-s most of the time too.  It depends
>      | on what you are actually doing.   If it is
>      | a fairly stable collection of data that
>      | doesn't get a lot written to it most of
>      | the time, it shouldn't matter.   If it is
>      | very volatile - lots of files come and go,
>      | then it could make a bigger difference.
>      | Unless it gets to the 100% mark (except
>      | for root) with that 100% being with the
>      | set-aside already taken out, it shouldn't
>      | cause anything to crash.
> _______________________________________________
> [EMAIL PROTECTED] mailing list
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Bill Moran
Potential Technologies
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to