On Nov 15, 17:16, Brian Tao wrote:
Subject: Re: soft quotas On Wed, 12 Nov 1997, Guy Harris wrote:
If that's acceptable to everyone, we can put that on the schedule; there's no technical problem with providing soft quotas compatible with those you get from a SunOS 4.x or 5.x *NFS server* when a *client* goes over the soft quota.
I think we need to at least get some of the basic server-siderequirements first:
Two limits for each quota type (including qtrees)
A grace period after which a soft quota becomes a hard quota
Mechanism to report quota information to a user-level process on an NFS client (e.g., rpc.rquotad)
Notifying the user in real time, as writes are performed to exceed
a soft quota, is probably not worth pursuing at this time. Client-side processes can be developed to handle the reporting and enforcing of local policy. The filer shouldn't go out of its way to actively warn the user... if your users don't read their .login warning messages or their warning e-mail, that's their problem. Having the server somehow outputting a human-readable message to the associated tty seems rather messy and icky.
Not to mention that the protocol probably doesn't have this feature already else I imagine the R&D guys at NetApp would've included something to use it already 8)
I don't like the idea of extending the protocol unless it's through a standards type process, with >1 vendor involved.
The filer will have to track each individual quota setting,incrementing and resetting grace timers as appropriate. When a grace period expires, the soft quota becomes a hard quota, and the NFS client will get EDQUOT's on writes. That's the only real-time notification I'm looking for.
Soft quotas on a quota tree could have some interesting effects.Doing a 'df' on an NFS filesystem would show the hard quota as the total fs size, while the "Used" and "Available" numbers would add up to the soft quota size. The difference between the soft and hard quotas can then be treated like the minfree threshold of a UFS filesystem, except you don't have to be root to exceed the soft quota.
Yah, Dave Hitz and I had a quick email dialogue where I kinda explained how we (ab)use qtree's here, and how the qtree quota would, for us, be best treated as an entirely different beast. We use qtree's to split up the reservoir of disk space in a filer so that a variety of projects can use network-mounted space but stay easy-to-administer. Lots'o users live in each qtree but you'd want user quotas to apply as well as the qtree quota. The qtree quota, as I see things, has no benefit to acrue from having soft limits - running out of quota in a qtree looks like you've just run right out of disk to a client and folk have learnt to handle that themselves.
-- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't" -- End of excerpt from Brian Tao