Xref: utzoo comp.unix.wizards:11405 comp.bugs.4bsd:1039 Path: utzoo!utgpu!attcan!uunet!mcvax!unido!ecrcvax!alan From: alan@ecrcvax.UUCP (Alan P. Sexton) Newsgroups: comp.unix.wizards,comp.bugs.4bsd Subject: Re: patch to du to restrict to one file-system Message-ID: <637@ecrcvax.UUCP> Date: 29 Sep 88 08:31:47 GMT References: <294@mars.UUCP> <632@ecrcvax.UUCP> <884@sword.bellcore.com> <5550@zodiac.UUCP> Reply-To: alan@ecrcvax.UUCP (Alan P. Sexton) Followup-To: comp.unix.wizards Organization: ECRC, Munich 81, West Germany Lines: 52 In article <5550@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >Mark Levinewrites: >> 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@ecrcvax.UUCP | from US: alan%ecrcvax.uucp@pyramid.pyramid.com