zemon@felix.UUCP (Art Zemon) (09/27/84)
I am considering beginning to run the disk quota software. If you have used it, please let me know how well it worked. Were there bugs which needed fixing? Do you have the fixes? Etc? -- -- Art Zemon FileNet Corp. ...! {decvax, ihnp4, ucbvax} !trwrb!felix!zemon
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/29/84)
The quota stuff works great. It slows down your booting process to check quotas (we have Gigabytes of disk) and when the whole filesystem fills up the operating system nicely crashes to keep it from getting any worse. Good luck (you'll need it)..
dave@uwvax.UUCP (Dave Cohrs) (09/29/84)
> I am considering beginning to run the disk quota software. > If you have used it, please let me know how well it worked. > Were there bugs which needed fixing? Do you have the > fixes? Etc? > -- > -- Art Zemon > FileNet Corp. > ...! {decvax, ihnp4, ucbvax} !trwrb!felix!zemon The disk quotas work pretty well. We use them here on our instructional systems. I don't remember any bug fixes, but I do know of one bug... If you update a disk quota for a person who is logged in (or has a process running with his/her uid) the machine will crash with a panic in the quota routines. So, generally, set quotas when the machine is in single. If you change them while it is up multiuser (new users is an exception, chances of them being logged in is minimal) you can crash things. -- Dave Cohrs @ wisconsin ...!{allegra,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave dave@wisc-rsch.arpa
lf@cornell.UUCP (Larry Fresinski) (10/01/84)
We've been using disk quotas for about a year with great results. We did modify /etc/rc so that a quotacheck wasn't done during a boot. To take the place of this we put the quotacheck into crontab and run it once per day when the system is light. This saves a lot of time when you want to get the system up as quiickly as possible.
lee@unmvax.UUCP (10/01/84)
> The quota stuff works great. It slows down your booting process > to check quotas (we have Gigabytes of disk) and when the whole > filesystem fills up the operating system nicely crashes to keep > it from getting any worse. > > Good luck (you'll need it).. We never crashed when our file-system filled... It is slower at boot. It confuses the *hell* out of the users. It gets bitched about alot, "But I absolutely, *must* have a Gig; please increase my quota." If (when.. please oh please) we get another disk they go out the door (for awhile at least) here. -- --Lee (Ward) {ucbvax,convex,gatech,pur-ee}!unmvax!lee
kre@mulga.OZ (Robert Elz) (10/01/84)
In article <451@uwvax.UUCP> dave@uwvax.UUCP (Dave Cohrs) writes: | If you update a disk quota for a person who is logged in (or has a process | running with his/her uid) the machine will crash with a panic in the | quota routines. So, generally, set quotas when the machine is in single. | If you change them while it is up multiuser (new users is an exception, | chances of them being logged in is minimal) you can crash things. There was a bug that caused a panic if quotas were changed for a user who had recently deleted a file (users logged in, or who have recently been logged in, usually delete quite a few files...). I suspect this is the bug referred to. I will post the fix to net.bugs.4bsd. (The panic this caused was "maknode: dquot", or "mkdir: dquot".) Robert Elz decvax!mulga!kre
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/02/84)
The file-system full crash may have been related to other 4.2BSD bugs and not the quota system. I did not feel like experimenting to find out!
discolo@ucsbcsl.UUCP (Anthony V. Discolo) (10/05/84)
>> I am considering beginning to run the disk quota software. >> If you have used it, please let me know how well it worked. >> Were there bugs which needed fixing? Do you have the >> fixes? Etc? >> -- >> -- Art Zemon >> FileNet Corp. >> ...! {decvax, ihnp4, ucbvax} !trwrb!felix!zemon > The disk quotas work pretty well. We use them here on our instructional > systems. I don't remember any bug fixes, but I do know of one bug... > If you update a disk quota for a person who is logged in (or has a process > running with his/her uid) the machine will crash with a panic in the > quota routines. So, generally, set quotas when the machine is in single. > If you change them while it is up multiuser (new users is an exception, > chances of them being logged in is minimal) you can crash things. You don't have to bring the system down to single user mode to update quotas, just use "/etc/quotaoff filesystem" to turn off quotas on that filesystem. Then after you're done, use "/etc/quotaon filesystem" to turn quotas back on. Quotas have worked well for us also, once we installed them. It was kind of a pain to install them though, since we had to find out how much disk space everyone was using (not hard), and then increment their usage by some constant (also not hard), and format that data for a program to set their quota. I also have a few general purpose quota programs that (safely) diddle with quotas, like given a block amount (+ or -), a filesystem, and a list of users, add the amount to each user's quota on that filesystem. (This is very hard to do with edquota(8)). If anyone would like the source for these, please send me mail. -- uucp: ucbvax!ucsbcsl!discolo arpa: ucsbcsl!discolo@berkeley csnet: discolo@ucsb USMail: U.C. Santa Barbara Department of Computer Science Santa Barbara, CA 93106 GTE: (805) 961-4178