Date: Sun, 14 Aug 2005 21:18:42 +0200 From: cpghost <cpghost@cordula.ws> To: Glenn Dawson <glenn@antimatter.net> Cc: Lei Sun <lei.sun@gmail.com>, questions@freebsd.org Subject: Re: disk fragmentation, <0%? Message-ID: <20050814191842.GA1358@bsdbox.farid-hajji.net> In-Reply-To: <6.1.0.6.2.20050814000146.0535bb50@cobalt.antimatter.net> References: <d396fddf050813235443c72213@mail.gmail.com> <6.1.0.6.2.20050814000146.0535bb50@cobalt.antimatter.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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. 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. > -Glenn -cpghost. -- Cordula's Web. http://www.cordula.ws/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050814191842.GA1358>