Hi! We have a large filesystem with 1,8 mio files and 16000 directories. Sometime developers think, they have to do some funny changes and start to fill up some directories within. as there are about 20 applications running, it is somehow difficult, to find out, who ist filling up the fs. "find . -print" runs 58 minutes, "du -s" runs for ages.
Is there any other way to find which directory is filling up??

thx

How about trying df -k

df -k tells you only the utilization of the *whole* filesystem, not the directories which are most responsible for the utilization.

I don't think there is a better way to analyze this than "du -ks * | sort -rn", but probably this runs for several hours on such a large filesystem.

A solution (well, not the most elegant one, but maybe better than nothing) would be to use a "spare" mirror and work on that, quasi-offline.

You create a mirrored filesystem (i don't know about your system, in AIX this is simple) or a third mirror if it is mirrored already. Regularly (say, once a day) you split one mirror off, mount this on some other machine as a FS and do your checks there. After being finished you can resync again with the original and split again the next time....

bakunin

I use df -k or df -h (Solaris 9 and above) to identify which disk slices are filling up. Then I do something like the following:

To find files that are 500k of characters or over

find / -xdev -size +500000c -exec ls -al {} \; | more

Does that help any ??

thx for input ... but ...

df only gives me the whole lot (what i allready have, because df in cron is setting the alarm). ANY find takes quite some while. find . -print for instance takes 59 minutes. So i think i have to strip down a global search into "sneaking" into specific directories to keep the response within a reasonable timerange (30 to 60 minutes). a pitty, that "du" always goes all way down it's tree in directory.