ggs@ulysses.UUCP (Griff Smith) (08/01/85)
> In article <133@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: > >Hostile users aren't the only good reason to have quotas. What about > >buggy software that gets into an infinite loop writing to a file? > > That's what "ulimit" is for. Don't use an SST when roller skates will do. If you haven't worked where people use UNIX systems to do real data processing, don't propose "ulimit" as an alternative to quotas. A 50 meg file won't even cause a batted eyelash here. When you lose half a day because you forgot to cast the proper spell to bypass a per-file size limit, per-file-system limits look much more attractive. The BSD quota system also supplies detailed, quickly-accessible, reports of disk usage. I don't have time to use combinations of "find" and "du" when the console is screaming "disk full". We set our quotas very high, but they are convenient fire walls. The first thing we do to "ulimit" is to set it to a huge value; the time lost due to hitting the standard value is just not worth it. -- Griff Smith AT&T Bell Laboratories, Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
hedrick@topaz.ARPA (Chuck Hedrick) (08/01/85)
How you do something matters as much as what you do. If you are into Control, I have little sympathy. It is crazy to think that quotas are going to let you decrease a user's disk usage below what he seriously believes he needs. But in a cooperative environment, they provide a convenient benchmark, that documents what the user has agreed to. The 4.2 quota system is particularly nice, since it forgives a few overages, and allows for more working space when logged in. They cause people to look at their file usage a bit more than they would otherwise, and to think for 30 seconds whether they really want to ask me for more space. That's useful, and about all one should expect.
root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) (08/03/85)
Having started this flamage I am really quite surprised at the varied opinions pro and con. I always assumed disk quotas weren't in V6 cuz it was intended for a clubhouse environment anyhow and slowly as sites got online with V7 etc they added them locally (Harvard I remember did this.) Finally, UCB added a good implementation to their distribution. I assumed SYSV didn't have it either because no one had bothered or no one had screamed (probably both.) So, I screamed I guess. Surprise, now people are claiming it's a philosophical issue (that's not a bug...) I guess it ain't obvious. Granted, it's worse in a student environment because so many people are learning to play with powerful software constructs (like creat()? well, yes.) Ok, people make mistakes (try "tar -f foo ." sometime on a 4.2 sys, maybe others I dunno.) These days, commercial environments are also faced with many non-technical users. Ulimit solves part of the problem but the extension to quotas is not very difficult, why not just solve the whole problem? To me Ulimit is a very non-unix'ish special case until someone thinks of a general tool, which is a quota system. Also, people can be lazy (I am carefully avoiding the 'malicious user' issue.) As far as the sum of the quotas being larger than the disk, that's probably ok, its a minority you are generally trying to control, we do it all the time, never had a problem. Yes, we have really really come down because of user accidents on quota-less systems, its embarrasing and the reaction usually is 'why didnt it stop me?' Unfortunately, disk is one of those resources that gets used up very passively (as opposed to CPU cycles or terminal lines.) It just accretes over time. On our research system we have no quotas, on our student system we have fairly liberal quotas (I don't think a student has asked for more yet, our UNIX sys is just over a year old for students.) The only place we have had troubles is our research system and the person always apologized and was usually unaware they had 'that much junk' [I send out mail messages occasionally to the top several users who often account for 50% or more.] Nope, no compromise on this one. I think its wrong that SYSV does not offer a disk quota system and it remains in my list of negative features when asked for a comparative evaluation from various people. I just don't like being woken up by a phone call from operations that a disk is full and the system is screaming (sometimes its not that trivial to fix.) I have never had any reaction but outrage over the lack of it from people listening to the comparison (that is, the people about to buy the system.) No, I am not hardnose about control, as I said, we run large systems without quotas as a matter of, not lack of, choice. If we go to quotas on those systems I will probably let people change their own quotas. -Barry Shein, Boston University "A toy shouldn't break just because a child plays with it" -- TONKA
geoff@desint.UUCP (Geoff Kuenning) (08/03/85)
In article <1025@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes (edited): > >If you haven't worked where people use UNIX systems to do real data >processing, don't propose "ulimit" as an alternative to quotas. A 50 >meg file won't even cause a batted eyelash here. When you lose half a >day because you forgot to cast the proper spell to bypass a per-file >size limit, per-file-system limits look much more attractive... >...We set our quotas very high, >but they are convenient fire walls. Sounds to me like quotas aren't really what you want, either. You don't want to set artificial limits on people's work (and any limit, no matter how high, is going to be a problem for someone someday). What you really want is an OS that doesn't make it nearly impossible to deal with exceptional conditions. UNIX's response to a filled disk comes from the "panic: out of swap space" days when nobody really wanted to write the tough code because it wasn't that important. If Berkeley (or AT&T) would put as much effort into the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily stop using quotas. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
tim@cithep.UucP (Tim Smith ) (08/05/85)
How should a system deal with a full (non {swap,pageing}) disk?
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!timspeck@cit-vax (Don Speck) (08/05/85)
Cit-vax is our general-use machine, with undergraduate classes,
grad students, and professors. It used to have disk quotas, but
when I was made system manager, I turned them off. Why? I noticed
that quota policy was primarily directed against class accounts,
which didn't stick around long enough to accumulate much in the
way of files; meanwhile, those in most need of restraint (the long-
time users of the machine) had infinite or extremely large quotas,
and disk usage to match. The disks were always full.
I turned off quotas because they were not serving to keep the
disk from running out of space, rather, they were serving to enforce
class distinctions. Of course, my decision may have been colored by
having been at the low end of this class structure before becoming
system manager... and my inability to say "no".
Don Speck speck@cit-vax.arpakre@ucbvax.ARPA (Robert Elz) (08/07/85)
In article <118@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) writes: > If Berkeley (or AT&T) would put as much effort into > the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily > stop using quotas. I would love to somehow handle full disk conditions gracefully, but can you suggest how? Swap errors (swkill stuff) is easy - kill the process with the problem. If the system had paniced the process would be killed anyway, so its no worse off, and the rest of the processes are considerably better off for not panicing. But how do I handle a full disk? Killing some random process won't fix it (not even killing ones writing to the full filesys). I could just delete some random files - but somehow I suspect their owners might get upset. So, does anyone have any good suggestions on how to sensibly handle full discs? The problem is really one of user control - only users know which of the allocated blocks on the disk contain useful information, and which contain trash. This seems to be a situation where avoiding the problem (by simply plugging in another eagle every week for preference, disk quotas if that answer isn't viable) is the only reasonable action. Robert Elz ucbvax!kre
sean@ukma.UUCP (Sean Casey) (08/08/85)
Disk quotas are good for stopping that overnight batch job that goes haywire
and loops while writing to a file. The SA comes in in the morning and finds
30 feet of console output complaining about a full disk.
For example:
shar -bcv * > sharfile
Something this innocent looking can do it.
--
- Sean Casey UUCP: sean@ukma.UUCP or
- Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean
- University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA kayuucee@cvl.UUCP (Kenneth W. Crist Jr.) (10/22/85)
Thanks to those people who responded to my request for info on disk quotas. Those of you who were thinking of responding, but haven't yet, thank you too. I really appreciate it. Kenneth Crist kayuucee@cvl