Thanks Istvan I'll remove everything and try again tomorrow...
I've downloaded CASACA 1.8.2 and installed it on our cluster.
cd /commun/data/packages/CASAVA_v1.8.2
mkdir CASAVA_v1.8.2-build
cd CASAVA_v1.8.2-build
../CASAVA_v1.8.2/src/configure --prefix=/commun/data/packages/CASAVA_v1.8.2
make
make install
here is the output of du -hs :
[root@master CASAVA_v1.8.2]# du -sh *
26G bin
135G CASAVA_v1.8.2
8.2T CASAVA_v1.8.2-build
2.0G CASAVA_v1.8.2.tar.bz2
1.0G etc
91G lib
47G libexec
809G share
8.2T !!! what is wrong ??? how can I clean this ? or can I just delete this CASAVA_v1.8.2-build ?
one big directory is:
du -hs /commun/data/packages/CASAVA_v1.8.2/CASAVA_v1.8.2-build/opt/bootstrap/
7.4T /commun/data/packages/CASAVA_v1.8.2/CASAVA_v1.8.2-build/opt/bootstrap/
2 answers
Something is not right with your original unpacked sources it should be pretty small to begin with. Most of the download size should in fact come from a few test datasets in the data folder.
ialbert@zeus /export/tools/down/CASAVA_v1.8.2
$ du -hs *
4.0K CODING
1.4G data
62M redist
8.9M src
Now your install seems to be 135GB at the source level. That seems wildly larger than in should be. Here is what I have if I freshly unpack the sources and the final compiled directory:
$ du -hs CA*
1.4G CASAVA_v1.8.2
1.4G CASAVA_v1.8.2.tar.bz2
981M CASAVA_v1.8.2-build/
(Perhaps your file system is going bad and as such it has started reporting wrong numbers)
Ok our sysadmin has just realized that he has allocated one block of 1 Go for each file in the NFS system.
( http://comments.gmane.org/gmane.comp.file-systems.xfs.general/31503 for reference )
Log in to answer this question.
Sounds like recursive build. What 'find . -type d -ls' says? Removing might be tricky, but 'find' has -delete option, which actually runs reasonably fast. EDIT: I've just noticed Istvan's comment - ok, maybe not recursive, as source directory is still 100x too large (haven't noticed before).