disk fragmentation, <0%?
lei.sun at gmail.com
Mon Aug 15 16:36:03 GMT 2005
This happened, after I tested the atacontrol to rebuild the raid1.
The /tmp partition doesn't have anything but several empty directories created.
and I have the clear /tmp directive in the rc.conf, which will clean
up the /tmp everytime when system boot up.
So that was really wierd. as it never happened this way the previous
time that I was rebuilding the raid1.
On 8/15/05, Freminlins <freminlins at gmail.com> wrote:
> On 8/15/05, Jerry McAllister <jerrymc at clunix.cl.msu.edu> wrote:
> > >
> > As someone mentioned, there is a FAQ on this. You should read it.
> > It is going negative because you have used more than the nominal
> > capacity of the slice. The nominal capacity is the total space
> > minus the reserved proportion (usually 8%) that is held out.
> > Root is able to write to that space and you have done something
> > that got root to write beyond the nominal space.
> I'm not sure you are right in this case. I think you need to re-read
> the post. I've quoted the relevent part here:
> > > Filesystem Size Used Avail Capacity Mounted on
> > > /dev/ar0s1e 248M -278K 228M -0% /tmp
> Looking at how the columns line up I have to state that I too have
> never seen this behaviour. As an experiment I over-filled a file
> system and here's the results:
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ad0s1f 965M 895M -7.4M 101% /tmp
> Note capacity is not negative. So that makes three of us in this
> thread who have not seen negative capacity on UFS.
> I have seen negative capacity when running an old version of FreeBSD
> with a very large NFS mount (not enough bits in statfs if I remember
> > ////jerry
More information about the freebsd-questions