Date: Mon, 15 Aug 2005 16:49:01 -0700 From: Lei Sun <lei.sun@gmail.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Jerry McAllister <jerrymc@clunix.cl.msu.edu>, questions@freebsd.org, cpghost <cpghost@cordula.ws>, Glenn Dawson <glenn@antimatter.net> Subject: Re: disk fragmentation, <0%? Message-ID: <d396fddf050815164938c84cae@mail.gmail.com> In-Reply-To: <20050815203917.GA75533@xor.obsecurity.org> References: <d396fddf05081421343aeded9d@mail.gmail.com> <200508151320.j7FDKCVq025507@clunix.cl.msu.edu> <20050815203917.GA75533@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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% fragmentatio= n. 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 Lei On 8/15/05, Kris Kennaway <kris@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 fu= ll? > > > > > > > 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. > > >=20 > In fact, you're both wrong, because that's clearly not what's going on > here (capacity <0, not capacity >100!) >=20 > 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. >=20 > Kris >=20 >=20 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d396fddf050815164938c84cae>