disk fragmentation, <0%?
lei.sun at gmail.com
Mon Aug 15 23:49:02 GMT 2005
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.
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.
More information about the freebsd-questions