On 04/08/99 18:51:42 you wrote:
I submitted a Request for Enhancment on how to solve this. Basically, I asked for something along the lines of:
Add a flag to the per-quota-entry data structure which the filer uses to maintain current state. If this flag is set, it indicates if a message has already been logged about that quota being exceeded.
Every time the quota entry is checked (during a disk write, or whatever), do the following: if (quota not exceeded) { flag = 0 } else { /* quota exceeded */ if (flag == 0) { syslog("quota exceeded ...") flag = 1 } } I.e, don't bother logging a message if that user has already had a message logged about them. However, if they go under quota, clear the flag, so we get a message when they exceed it again.
The only response I've received (second hand) is along the lines of ``we've fixed it, but a different way''.
Yeah, this has been a well known problem for years, but I had trouble getting action on it until engineers actually had to deal with the problem first hand and realized just how bad it was. As to the fix, I don't recall what it was, but I recall a proposal similar to the one you listed being considered and rejected (for example, your suggestion wouldn't work, since when the user fails to go over quota they'll generally fall right back under it, thus resetting the flag).
[Hmm; I should put support@netapp.com (or whatever) on autosupport; maybe then they'll listen after getting a 30MB email message every week ;-]
I think they already filter such things.
Bruce
sirbruce@ix.netcom.com writes:
I.e, don't bother logging a message if that user has already had a message logged about them. However, if they go under quota, clear the flag, so we get a message when they exceed it again.The only response I've received (second hand) is along the lines of ``we've fixed it, but a different way''.
Yeah, this has been a well known problem for years, but I had trouble getting action on it until engineers actually had to deal with the problem first hand and realized just how bad it was. As to the fix, I don't recall what it was, but I recall a proposal similar to the one you listed being considered and rejected (for example, your suggestion wouldn't work, since when the user fails to go over quota they'll generally fall right back under it, thus resetting the flag).
Well, extend the concept slightly further; have a per volume or per filer option which has one of the following values (in ascending order of quietness): 1. Log everytime quota is exceeded. (Current behaviour, which is bad for my environment) 2. Log first time quota is exceeded; reset `first time' flag once quota drops below the limit. (My initial suggestion, and would still be useful in those situations where you drop people's quota) 3. Log first time quota is exceeded, and don't log again until a quota on/resize has been performed 4. Log first time quota is exceeded, and don't log again until a user specified time frame has exceeded (e.g, once per day).
The advantage that I can see of such a flag is that you would probably have it on either `3' or `4' in production, but you can tweak it on the fly if you were debugging a problem.
It would also be really nice to know what syslog facilities and levels are used for each type of message. E.g, if `local5' was only used for quota messages, and `info' was quota exceeded messages. This way, you could also do: *.debug,local5.warning /etc/messages to log all messages except quota messages < warning (i.e, the exceeded messages)...
Documentation of this shouldn't be too hard, really... I'd love to RTFS to find this out, but I can't ;-)
-
Luke Mewburn -
sirbruce＠ix.netcom.com