disk fragmentation, <0%?

Glenn Dawson glenn at antimatter.net
Sun Aug 14 20:30:02 GMT 2005

At 12:18 PM 8/14/2005, cpghost wrote:
>On Sun, Aug 14, 2005 at 12:09:19AM -0700, Glenn Dawson wrote:
> > >2. How come /tmp is -0% in size? -278K? What had happened? as I have
> > >never experienced this in the previous installs on the exact same
> > >hardware.
> >
> > Not sure about that one.  Maybe someone else has an answer.
>This is a FAQ.
>The available space is always computed after subtracting some space
>that would be only available to root (typically around 5% or 10%
>of the partition size).

The default is 8%.

>  This free space is necessary to avoid internal
>fragmentation and to keep the file system going. Root may be able
>to "borrow" some space from this (in which case the capacity goes
>below 0%), but it is not advisable to keep the file system so full,
>so it should be only for a limited period of time.

The reason for having the reserved space is to allow the functions that 
allocate space to be able to find contiguous free space.  When the disk is 
nearly full it takes longer and longer to locate contiguous space, which 
can lead to performance problems.

>In your example, you're 278K over the limit; and should delete some
>files to make space ASAP. Should /tmp fill up more, it will soon become

 From the original message:

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ar0s1e    248M   -278K    228M    -0%    /tmp

This shows that /tmp is empty.  If the reserved space was being encroached 
upon, it would show > 100% capacity, and available bytes would go negative, 
not bytes used.

It would look something like this:

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    248M    238M    -10M   105%    /

I've never seen the capacity go negative before, which is why I suggested 
someone else might know the answer.


More information about the freebsd-questions mailing list