Path: utzoo!attcan!uunet!convex!killer!ames!nrl-cmf!cmcl2!rutgers!bellcore!faline!thumper!ulysses!gamma!sword!arrow!yba
From: yba@arrow.bellcore.com (Mark Levine)
Newsgroups: comp.unix.wizards
Subject: Re: patch to du to restrict to one file-system
Message-ID: <897@sword.bellcore.com>
Date: 1 Oct 88 01:14:29 GMT
References: <294@mars.UUCP> <632@ecrcvax.UUCP> <884@sword.bellcore.com> <5550@zodiac.UUCP> <637@ecrcvax.UUCP>
Sender: news@sword.bellcore.com
Reply-To: yba@sabre.bellcore.com (Mark Levine)
Organization: Bellcore, Red Bank, NJ
Lines: 29

>Perhaps I should have explained why I think this feature is necessary.
>The problem I was trying to deal with neither quotas or quot can solve.
>The problem was that sometimes a filesystem would fill up - usually /usr
>due to a logging file that I'd forgotten or never known about. Quota and
>quot doesn't help in this case (it tells you that root owns a large amount of
>disk space, bin owns a large amount of disk space etc. but no real pointers
>to the culprit. In fact the culprit may be a large program that was compiled but
>hadn't had the .o files removed or something like that).

This is in fact a horse of another color.  If you have no clue about what
happened or when from user accounting or whatever, you still have to look
at an entire file system.  Your concern seems to be not traversing mounted
files systems while up multi-user; there are several programs that work
explicitly on file systems and will constrain themselves, for example:
ncheck (gives you a list of all inodes and their file names on a given
system).  With such a list you still have to do some post processing to
tell the size of each, and perhaps the quot(8) suggestion is right on the
mark for this: quot -n /dev/r<file_system>.  It will not be fast.

Finding a culprit without keeping audit trails requires search, and if you
were willing to put up with du, I think you will be willing to put up with
quot.  You can always use your own ncheck based pipeline to list and sort
all files by size, perhaps discarding those too small to be of interest.

I don't read the group you have redirected to, so please forward a copy of
more useful suggestions (I reserve the right to learn better at all times!).

Eleazor bar Shimon, once and future Carolingian
yba@sabre.bellcore.com