I have to chime in with my tip, although john has solved the issue.
First, the biggest issue with / as john saw was that there are lots of
mount points created in the root partition. If somehow one doesn't get
made and then later is made, you can't find the problem easily as some
space use is hidden under the mount. Second, normal du traverses all the
mount points meaning you have to ignore lots of du output, making it
difficult to see what's going on. finally du prints data as it's seen,
and you want to focus attention on big things. Here is my solution and
since it's / it must be done as root
sudo du -d 2 -x / |sort -n
The -x prevents recursing into the mounted file systems, -d 2 prints
data for the top 2 directory levels, (unfortunately you cant use -h
because the human readable sizes don't sort well), but this du with
sort, shows directories sorted by size (usually k bytes), so little
things like
36 /etc/logwatch
come first and the big this last
22353524 /var/cache
so you can easily target which subtrees are of interest. Unfortunately,
du doesn't (and shouldn't) unmount things to see whats under the mount
points, so the tip off for that, is to look at the final total
42368200 /
and if it doesn't match what df says, you know the rest is in the hidden
mounts. in my case df / says
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda4 51475068 42424736 6412508 87% /
which is close.
Once you have a few big directories to look at, can drill down another
level to see what's using the space, of course if the du and df's
disagree by a lot your stuck with the fact that it's probably a
directory hidden under a mount. So at least the search is narrowed, to
reflecting on mount activity, and checking things like usb mounts that
don't exist from boot to shutdown.
steve
Russell Johnson wrote:
>
>> On Oct 24, 2017, at 10:18, John Jason Jordan <[email protected]> wrote:
>>
>> I recently encountered this and it turns out that my / partition was,
>> indeed, full. At the last Clinic I added ~50GB of free space on the
>> drive to /, making now a total of 84GB. And now it is happening again.
>> Something in / has eaten the entire new space.
>>
>> Note that ~/ is on the same drive, but a different partition. According
>> to Thunar the ~/ partition is only 64% used, 138GB of free space.
>> The device is a 480GB SSD. Palimpsest shows both partitions and no
>> unallocated space.
>>
>> I used Thunar to check Properties on everything in / and found nothing
>> out of the ordinary. I need some command line tools to find the pig
>> that is using all my space. Also I need to find out what is causing the
>> pig to be so hungry. Suggestions?
>> _______________________________________________
>> PLUG mailing list
>> [email protected]
>> http://lists.pdxlinux.org/mailman/listinfo/plug
> This is way more complicated than you need, but I use it all the time to find
> where space has gone. When you run this as root or sudo, it will list each
> directory and how much space it takes.
>
> FWIW, without reading the thread, I suspect /var/log.
>
> Everyone be gentle. I wrote this years ago before I learned much about
> scripting, and it works, so I haven’t messed with success.
>
> #!/bin/bash
>
> OUTFILE=/tmp/dirs.$$
> SORTED_OUTFILE=/tmp/sorteddirs.$$
>
> OLDIFS=$IFS
> IFS=$'\n'
>
> for each in `ls -1A`; do
> echo "Processing $each..."
> du -ksx $each >> $OUTFILE
> done
>
> echo "Directory usage for `date +%m%d%y%H%M%S`" > $SORTED_OUTFILE; echo >>
> $SORTED_OUTFILE
>
> sort -nr $OUTFILE >> $SORTED_OUTFILE
>
> rm $OUTFILE
>
> less $SORTED_OUTFILE
> rm $SORTED_OUTFILE
>
> IFS=$OLDIFS
>
>
> —
>
> Russell Johnson
> [email protected]
>
>
>
>
> _______________________________________________
> PLUG mailing list
> [email protected]
> http://lists.pdxlinux.org/mailman/listinfo/plug
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
