Re: Is my disk too crowded ?

[David Wright <deblis@lionunicorn.co.uk>]

Quoting Charles Blair (c-blair@illinois.edu):
>    I have been recently noticing that the find
> command is taking a long time, and my /usr (see df
> output below) is 73% full.  Should I do something?
> 
>    libreoffice seems to be using a lot of space, and
> I only use it to read .doc files other people send me.
> I don't use the spreadsheet or database features.
> Is some reduced-functionality version available?
> 
> Filesystem                   1K-blocks    Used Available Use% Mounted on
> rootfs                          330215  189549    123617  61% /
> udev                             10240       0     10240   0% /dev
> tmpfs                           400736     696    400040   1% /run
> /dev/disk/by-uuid/0923b264-e    330215  189549    123617  61% /
> tmpfs                             5120       0      5120   0% /run/lock
> tmpfs                          2457480      76   2457404   1% /run/shm
> /dev/sda10                   176581224 1423588 166187808   1% /home
> /dev/sda9                       376807   10270    347081   3% /tmp
> /dev/sda6                      8649992 5967084   2243512  73% /usr
> /dev/sda7                      2882592  495636   2240524  19% /var

Tricky to answer without knowing what sort of functionality/package
mix you have. On my own wheezy box (X and fvwm, no desktop), /usr
looks like:

   8700M             /usr/
    290M                 /usr/bin/
      1M                         /usr/games/
     17M                     /usr/include/
   1884M             /usr/lib/
      1M                         /usr/local/
     12M                     /usr/sbin/
   6388M             /usr/share/
    112M                 /usr/src/

Delving in, we find (sorted by size):

     67M                     /usr/lib/gcc
     76M                     /usr/lib/iceweasel
     81M                     /usr/lib/python2.6
     84M                     /usr/lib/python2.7
     93M                     /usr/lib/jvm
    154M                 /usr/lib/chromium
    324M                 /usr/lib/libreoffice
    504M                 /usr/lib/i386-linux-gnu
   1884M             /usr/lib

     31M                     /usr/share/libreoffice
     33M                     /usr/share/man
     33M                     /usr/share/midi
     39M                     /usr/share/inkscape
     44M                     /usr/share/help
     47M                     /usr/share/java
     52M                     /usr/share/gimp
     59M                     /usr/share/pyshared
     65M                     /usr/share/emacs
    101M                 /usr/share/icons
    102M                 /usr/share/fonts
    151M                 /usr/share/texmf
    153M                 /usr/share/sounds
    317M                 /usr/share/locale
    337M                 /usr/share/openclipart
    619M                 /usr/share/texlive
   1579M             /usr/share/openclipart2
   2217M             /usr/share/doc
   6388M             /usr/share

The culprits in doc are texlive and lilypond which are two of the most
important systems for me. I've already filed a bug against the sizes
of the files in openclipart; if space were short, I would get rid of
openclipart2 too because I think most of it is on the web.

I only use / and /home partitions, so I create 32G root partitions nowadays.
That leaves plenty of room for anything up to 10G of
/var/cache/apt-cacher-ng on whichever box I run it on.
Laptops a little less. The above generated with

function duse {
    local DIR=$(realpath "${1:-.}")
    ( for j in $(find "$DIR" -maxdepth ${2:-1} -type d) ; do
	  du --si -s -BM "$j" ; done ) | sort -k 2 | expand | sed -e 's/\([0-9.M]*\)\( *\)/\2\1 \2\2\2\2/'
}

and | sort -h as appropriate.

Cheers,
David.