disk fragmentation, <0%?

Lei Sun lei.sun at gmail.com
Mon Aug 15 23:49:02 GMT 2005

Thanks All,

I think Kris's suggestion worked, as when I was rebuilding of the
atacontrol, I remember it failed once, and had a lot of problem trying
to reboot and unmount the /tmp directory.

So after I rebuild the array, somehow /tmp looks clean to the OS, and
didn't get checked.

so somehow the the stats was not showing the correct information.

I have already rebuild the machine, all of the effect from the
atacontrol rebuild array are gone now, and it seems like everything is
back to normal.

Capacity is right, Used is right, Avail is right, and all 0.0% fragmentation.

Then, my other question is,

If the file space allocation works like Glenn said earlier, how come
with the exact same files from 2 different installations using the
exact procedures, can result in different fragmentation?

in the atacontrol raid1 failure case, /dev/ar0s1a: ... 0.5% fragmentation
in the new build case, /dev/ar0s1a: ... 0.0% fragmentation

That doesn't seems to make a lot of sense.

Thanks again


On 8/15/05, Kris Kennaway <kris at obsecurity.org> wrote:
> On Mon, Aug 15, 2005 at 09:20:12AM -0400, Jerry McAllister wrote:
> > >
> > > Thanks for the good answers.
> > >
> > > But can anyone tell me why the capacity is going negative? and not full?
> > >
> > > > Filesystem     Size    Used   Avail Capacity  Mounted on
> > > > /dev/ar0s1e    248M   -278K    228M    -0%    /tmp
> >
> > As someone mentioned, there is a FAQ on this.   You should read it.
> >
> In fact, you're both wrong, because that's clearly not what's going on
> here (capacity <0, not capacity >100!)
> The only thing I can think of is that you have some filesystem
> corruption on this partition that is confusing the stats.  Try
> dropping to single-user mode and running fsck -f /tmp.
> Kris

More information about the freebsd-questions mailing list