alan@ecrcvax.UUCP (Alan P. Sexton) (09/23/88)
In article <294@mars.UUCP> rich@cfi.COM (Rich Baughman -CFI-) writes: >How many times have you frantically had to answer this question: > > "Who is using up all the #&$%@ space on this disk?!". > >This happens to us all the time. Does anyone know of the existence of a >program like 'du' that shows disk use by directory for a specific file system >(i.e., one that does not traverse mounted file systems)? I include a context diff to add a -d argument to du. With this arg du will report 0 size for any directory being used as a mount point and it will not traverse the mounted filesystem. The sources are for BSD4.[23] on a Vax. We've been running this for some years on our systems without problems. Note that any files you have in the mount point directory do not show up to du or ls even though they do take up real disk space which is reported by df. This can be a source of missing disk space (/tmp is particularly prone to this problem if you mount a separate file system on it: i.e. do some work in single user mode or with /tmp otherwise unmounted and forget to clear out the /tmp mount point before going multiuser. On going multiuser the /tmp filesystem is mounted over the /tmp mount point and you no longer see the files you used to have in /tmp). >BTW, we do not have a source license, so those >solutions are out. Sorry: maybe someone will include it as a standard feature in the next release. Warning: the line numbers may be different to your sources. *** du.c.orig Fri Sep 23 10:11:38 1988 --- du.c Tue May 26 10:20:57 1987 *************** *** 1,6 **** --- 1,7 ---- #ifndef lint static char *sccsid = "@(#)du.c 4.11 (Berkeley) 7/1/83"; #endif + #define ECRC #include <stdio.h> #include <sys/param.h> *************** *** 10,15 **** --- 11,21 ---- char path[BUFSIZ], name[BUFSIZ]; int aflg; int sflg; + #ifdef ECRC + /* APS: added arg '-d' to restrict a search to one disk filesystem */ + int dflg; + int orig_dev = -1 ; + #endif char *dot = "."; *************** *** 45,50 **** --- 51,64 ---- argc--, argv++; goto again; } + #ifdef ECRC + /* APS: '-d' addition */ + if (argc && !strcmp(*argv, "-d")) { + dflg++; + argc--, argv++; + goto again; + } + #endif if (argc == 0) { argv = ˙ argc = 1; *************** *** 102,107 **** --- 116,135 ---- *ebase0 = 0; return (0); } + #ifdef ECRC + /* APS: '-d' addition */ + if (dflg) + { + if (orig_dev == -1) + orig_dev = stb.st_dev ; + else if (stb.st_dev != orig_dev) + { + if (sflg == 0) + printf("%ld\t%s\n", 0l, base); + return (0) ; + } + } + #endif if (stb.st_nlink > 1 && (stb.st_mode&S_IFMT) != S_IFDIR) { for (i = 0; i <= mlx; i++) if (ml[i].ino == stb.st_ino && ml[i].dev == stb.st_dev)
yba@arrow.bellcore.com (Mark Levine) (09/24/88)
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. Even if you don't want to enforce small quotas, you can give all users unbounded use of the disk and still get a report of who is using how much across logins. And, of course, if you do need to enforce limits on use, well, it is designed for same. Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
jordan@zooks.ads.com (Jordan Hayes) (09/25/88)
Mark Levine <yba@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. Even if you don't want to
enforce small quotas, you can give all users unbounded use of
the disk and still get a report of who is using how much across
logins.
Gee whiz, doesn't anybody read manuals anymore?
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 ...
/jordanyba@arrow.bellcore.com (Mark Levine) (09/26/88)
In article <5550@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >Mark Levine <yba@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.... > >Gee whiz, doesn't anybody read manuals anymore? > >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 ... > Agree with the second. On the first we differ in that quot can take a long time, as opposed to "quota user" which just reads a precomputed file for you. The quota hacks in the kernel aren't near as slow as the quotacheck on boot, so your way is still well worth considering! The nice thing about having quota turned on is you can _do_ something about the numbers you see -- depending on how big your disk farm is and how many users you have, there are going to be tradeoffs. Whether you want your users to take the action or whether you expect it to be your job to remove files is part of that trade-off. (Gee whiz, how did you get manuals? They won't buy us any here, they claim UNIX is trivially obvious and everything can be intuited with a little effort.) Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
arosen@hawk.ulowell.edu (MFHorn) (09/26/88)
From article <5550@zodiac.UUCP>, by jordan@zooks.ads.com (Jordan Hayes): > Mark Levine <yba@sabre.BellCore.COM> writes: > just use the quota mechanism. Four of the six versions of Unix at our site (up and running that I can thinkg of) don't have quotas. > Gee whiz, doesn't anybody read manuals anymore? > What about quot(8)??? Not all versions of Unix have quot. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
jordan@zooks.ads.com (Jordan Hayes) (09/26/88)
Mark Levine <yba@sabre.Bellcore.COM> asks: Gee whiz, how did you get manuals? You might like this: % man man /jordan
yba@arrow.bellcore.com (Mark Levine) (09/27/88)
In article <5552@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >You might like this: > > % man man > >/jordan Ok, I guess they aren't kidding -- from now forward I will include explicit humor indicators whenever using sarcasm. Please correct the earlier statement to Gee, how did you get them to buy you manuals.... to the same followed by ... :-) In any case, I agree this was not a bsd bug with du. Profiled and timed execution of quota code, shell pipelines for determining disk usage, and email to offenders versus setting of quotas I think are left as an exercise to the universe. Perhaps this can be moved to news.sysadmin or alt.flame now? Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com
jfh@rpp386.Dallas.TX.US (The Beach Bum) (09/28/88)
In article <9300@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: >From article <5550@zodiac.UUCP>, by jordan@zooks.ads.com (Jordan Hayes): >> Gee whiz, doesn't anybody read manuals anymore? >> What about quot(8)??? > >Not all versions of Unix have quot. all berkeley versions should since it came from version 7 and berkeley never leaves anything out ;-). i have a version i have run on several modern USG systems. i might be persuaded to post it. it might need some porting for your machine so don't expect a miracle. -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
alan@ecrcvax.UUCP (Alan P. Sexton) (09/29/88)
In article <5550@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >Mark Levine <yba@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@ecrcvax.UUCP | from US: alan%ecrcvax.uucp@pyramid.pyramid.com
yba@arrow.bellcore.com (Mark Levine) (10/01/88)
>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