Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 May 2008 07:31:25 GMT
From:      "gs_stoller@juno.com" <gs_stoller@juno.com>
To:        jerrymc@msu.edu, hartleigh.burton@destra.com, colin@ips.gov.au
Cc:        freebsd-questions@freebsd.org
Subject:   Re: a monster stole my /
Message-ID:  <20080507.033125.29340.1@webmail07.dca.untd.com>

next in thread | raw e-mail | index | archive | help
On Tue, Apr 29, 2008 at 11:34:54 -0400 Jerry McAllister wrote:
> On Tue, Apr 29, 2008 at 02:40:09PM +1000, Hartleigh Burton wrote:
>> Hiya!
>> =

>> I have a problem with / currently being at 108% capacity. I have foun=
d  =

>> a previous thread in the archives which explains a few questions but =
I  =

>> can't find what is taking up all the additional space. At best withou=
t  =

>> destroying what I still do not understand I can manage to get / to  =

>> about 101% capacity.
> oI see you have used du.   I usually do   =

>                                          cd /
>                                          du -sk *
> Since the 'h switches between K, G, M,  I find it a little harder
> to eyeball than picking just one of K, M or G.    I also find the -s
> more useful in a general situation than -dn since it gives a =

> good general summary.
> The one thing I can think of would be some file that has been rm-ed
> but not released by some process.   The space will still stay allocate=
d
> until the file is released by all processes.   A reboot can help that.=

> If reboot doesn't free anything up, then you have some serious digging=

> to do.    Your / file system is quite large and you have most of the
> usually culprits moved somewhere else.   So, you should not need =

> anywhere near that much disk for /.
The arithmetic is being done by a computer program which must have maxim=
um sizes set for numbers (e.g., long [4 bytes], maybe  ulong , etc.), no=
t by a human being who can adjust for the size of the data (though he ma=
y make other mistakes).  Try to get the raw data on which the arithmetic=
 is done to see if the error may be there, and you could point to a prog=
ram needing a correction (which may not be possible unless one goes to f=
loating point which causes other problems)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080507.033125.29340.1>