Xref: utzoo comp.unix.questions:14789 comp.unix.wizards:17193 Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: chown (was: at files and permissions) Message-ID: <34422@bu-cs.BU.EDU> Date: 9 Jul 89 15:38:15 GMT References: <1894@cbnewsh.ATT.COM> <669@lzaz.ATT.COM> <8072@bsu-cs.bsu.edu> <4884@ficc.uu.net> <18414@mimsy.UUCP> <10501@smoke.BRL.MIL> Organization: Boston U. Comp. Sci. Lines: 94 From: gwyn@smoke.BRL.MIL (Doug Gwyn) >There seem to me to be two valid services that can be performed >by a disk "quota" system. One of them is to prevent runaway disk >consumption such as > cat x >> x >and the other is to keep users from accumulating junk that fills >the available disk. The first problem is dealt with adequately >by a resource limit mechanism a la ulimit, or more reliably by a >"dynamic" quota monitor attached to the specific session. The >second problem can be dealt with administratively, with periodic >use of "du|sort -rn" to find where the problems are. Realistic >long-term storage quotas really have to be negotiated between the >users and the system administrator anyway. These methods of >providing disk quota services do not encounter the scenario that >you described for the UID-based quota scheme when the file owner >is allowed to chown his own file. No, it can't be dealt with with "du|sort -rn" except on very small systems where you can probably just say "someone's hogging the disk" loudly and get the same effect, cause everyone's in the same room anyhow (ok, I exaggerate, but small systems with perhaps a hundred or two entries in the password file.) Or, of course, where you charge hard currency for disk space so the system has built-in feedback which makes such problems relatively rare (on one system like that at Harvard I was the "disk hog", but my funds solved the problem simply enough, they bought me my own washing machine, no tears.) Consider the system Rob Pike was describing in his recent USENIX talk. One major component was a large, organization-wide file server. This is the type of system that easily has tens of thousands of accounts (that's not unusual, I worked with a non-unix system over the last few years that had over 15,000 login accounts in the password file.) You can have dozens if not hundreds of people using more than what was decided was their fair share of disk every day. So you run this script and send them mail. So what? So twenty of them went over their fair share and won't be back for weeks to see your mail (negligently or otherwise, they may have thought they had a good reason to do whatever they did) are way over quota and the disk is busting at the seams on some partitions. Another ten are ignoring you. Don't tell me, you start moving some of their stuff off to tape. Oh what fun, let's have about two dozen people to run this system just to handle sending and answering disk quota mail, putting things to tape, dealing with irate users who find they were put to tape and are quite sure you are mistaken and have inconvenienced them (or believe they can play the political game to make you never do that to them again), get the stuff off tape, deal with people who are quite sure something has gone wrong in this restoral not to mention a phone call or two about how it took so damn long and they now have a dozen people idle which is costing them about a thousand dollars an hour while you deal with the others who are being difficult (ie. human), etc etc etc. Sh*t Doug, I'd own your whole disk farm just by making you do things by written, signed memo. You'd spend your weekends proposing budgets for another dozen secretaries. Obviously little systems don't need quotas very badly (tho, hey, they solve both problems you describe with one model, why introduce two systems where one will do?) The correct answer is that if you personally shouldn't be constrained to quotas either you should have infinite quotas or access to some (set[gu]id) program which lets you set your own quotas (so problem #1, the accidental overrun is still averted, if desirable.) Disk is a finite, valuable resource. Many organizations must manage their disk with many users from diverse administrative domains, and manage it without any realistic chargeback scheme (ie. the disk is essentially or actually free* as far as any individual user is concerned.) The simplest, most obvious way to do this is to assign disk quotas and have the software enforce these quotas automatically instead of turning some poor sap into your local disk slave heavy. My suspicion is you've never managed large systems like this or you wouldn't even dream of suggesting to just send mail to offenders. And they're not rare (hint: just about every university has at least one, if not a few dozen, such systems.) -------------------- * In fact it's often worse than "free" since the disk is being paid for out of overhead by everyone so anything you can grab for yourself is a boon to you, kinda like taxes, you actually can win as long as you're getting more than your fair share and someone else isn't. Sorry, but that's life, you don't fix it by removing quotas. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs