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
inoperable.
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.
-Glenn
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
