patch to du to restrict to one file-system

[Alan P. Sexton]

In article <5550 at zodiac.UUCP> jordan at ads.com (Jordan Hayes) writes:
>Mark Levine <yba at sabre.BellCore.COM> writes:
>>	If this is a recurring problem with your system (how to find
>>	out who is using the disk space), you may find it worthwhile to
>>	just use the quota mechanism.
>What about quot(8)??? -- you don't need those slow quota hacks in yer
>kernel just to find out who owns the files, and you don't need feeping
>creaturism on du ...

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).

If the problem is with the root file system or /usr file system then
normal du or find will take a loooong time an then post-processing is necessary
which adds to the work. The best way to track down the problem
is to go single user and unmount the filesystems mounted underneath the
problem system and do a du or find on the problem system. This is a real
pain. I don't have this kind of problem with user file systems because
there is never anything mounted underneath a user system at my site.

As far as creaping featurism is concerned I would agree wholeheartedly
if there was a shell script or set of standard command that would do what
I wanted, even if it took 4 or 5 times as long to do it that way.
I wasn't able to figure out a satisfactory one. Adding the -d option
to du seemed simple and logical. A similar feature could be added to find
but since I have never needed it once I changed du I think it would
really have been creeping featurism to put it in.

I don't think the lack of the -d option is a bug in du. I do think
the lack of this kind of facility is a bug in the system administration
facilities of unix.

I haven't mentioned remote file systems and the problems that occur
with them though I wonder how Dennis Ritchie tracks down these sort of
problems on his machine where find and du runs forever due to loops in
the file system mounting scheme [see Peter Weinbergers paper in the
Florence Spring 86 EUUG conf]. Perhaps they just never occur.

p.s. I've directed followups to unix-wizards as I don't think this sort of
discussion should be cross-posted to bugs.4bsd.

Alan Sexton					tel. (089) 92699164
European Computer-Industry Research Centre (ECRC)
Arabellastr 17, 8000 Muenchen 81, West Germany
mcvax!unido!ecrcvax!alan  | from US:	...!pyramid!ecrcvax!alan
alan at ecrcvax.UUCP	  | from US:	alan%ecrcvax.uucp at pyramid.pyramid.com