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.
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}!timkre@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