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-side requirements first:
1. Two limits for each quota type (including qtrees) 2. A grace period after which a soft quota becomes a hard quota 3. 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.
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.