Date: Fri, 30 Dec 2005 18:43:37 +1300 From: Mark Kirkwood <markir@paradise.net.nz> To: olivier@gautherot.net Cc: freebsd-hardware@freebsd.org Subject: Re: Harddrive size being reported incorrectly? Message-ID: <43B4C909.8020006@paradise.net.nz> In-Reply-To: <200512292136.50983.mlalvarez@manquehue.net> References: <200512292134.jBTLYaSH001273@clunix.cl.msu.edu> <200512292136.50983.mlalvarez@manquehue.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Olivier Gautherot wrote:
> On Thursday 29 December 2005 18:34, Jerry McAllister wrote:
>
>>>>[...]
>>>>When you slice and partition the drive, there will likely be a handful
>>>>of sectors that don't round out to an even value so those are dropped.
>>>>Then, when you do the newfs, some space is taken by the spare superblocks
>>>>and finally the system reserves 8%. So, I would say you are getting
>>>>it all.
>>>
>>>289GB is before the 8% reservation. I actually turned that off with tunefs.
>>
>>I strongly suggest you do not do that - at least completely off.
>>Reduce it some, if you like, but keep some.
>
>
> I too strongly recommend you keep these 8% in.
>
> The fact is that the space is not wasted: in the old days, it was meant
> to prevent the system from happily creating files until it dies - beyond
> 100%, files already opened could be written to but you could not create
> new files. Some kind of "soft landing". I suppose it is still the case.
>
> Actually, a friend asked me a few weeks ago how the file system could
> reach 110% and he was speculating on how the system could use the
> swap partition to get to this level: it was not the swap partition but this
> extra space artificially held up.
>
> You can safely and without afterthoughts let this 8% in.
>
In addition, there are some potentially undesirable side effects that
result from reduction - from the tunefs manpage discussing minfree:
<quote>
Note that lowering the threshold can adversely affect performance:
o Settings of 5% and less force space optimization to always be
used which will greatly increase the overhead for file
writes.
o The file system's ability to avoid fragmentation will be
reduced when the total free space, including the reserve,
drops below 15%. As free space approaches zero, throughput
can degrade by up to a factor of three over the performance
obtained at a 10% threshold.
</quote>
The first effect can be mitigated by specifying '-o time', but I always
leave it at the 8% default (fewer customizations for me to forget...).
Cheers
Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B4C909.8020006>