A couple of notes about quotas-- I know this has been brought up before but the negative effects that occur when a user is over quota are still disconcerting.
Ideally it would be best if a user could at least delete mail when in an over-quota condition. One would think it would be enough to simply ignore errors creating the index files (and use an in-memory index). However, another problem is that the mere renaming of a file from the new/ directory to the cur/ directory can cause an over-quota error if the cur/ directory has to be expanded. We see these errors in the maillog followed by an "I/O leak" message, e.g.:
Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): maildir build: rename(/users/3a/someuser/Maildir/new/1049919998.23875.mercury.mv.net, /users/3a/someuser/Maildir/cur/1049919998.23875.mercury.mv.net) failed: Disc quota exceeded Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): I/O leak: 0x807361c (1) Apr 21 07:42:26 mercury mem[10059]: pop3(someuser): I/O leak: 0x804a1b8 (0)
and then we get a report about the server dropping the connection.
BTW we seem to see quite a lot of these "I/O leak" messages in other situations too, and I think it started with the test5 release (but I am not absolutely sure). What does this mean?
Yours, mm
On Mon, 2003-04-21 at 17:47, Mark E. Mallett wrote:
A couple of notes about quotas-- I know this has been brought up before but the negative effects that occur when a user is over quota are still disconcerting.
Ideally it would be best if a user could at least delete mail when in an over-quota condition. One would think it would be enough to simply ignore errors creating the index files (and use an in-memory index). However, another problem is that the mere renaming of a file from the new/ directory to the cur/ directory can cause an over-quota error if the cur/ directory has to be expanded. We see these errors in the maillog followed by an "I/O leak" message, e.g.:
Hmm. I'm not sure how to fix this properly. I can of course just ignore those files in new/, but then user can't delete those messages. Maybe I should allow keeping the files in new/ in out-of-disk-space conditions..
uidlist file is also problematic. If there's no disk space to build new one, the UIDs can't be permanently saved. Or worse, they could be reused for different messages breaking client's cache.
BTW we seem to see quite a lot of these "I/O leak" messages in other situations too, and I think it started with the test5 release (but I am not absolutely sure). What does this mean?
It's mostly debugging. Some file descriptor was added to poll() (or similiar) list, but wasn't removed from there. I'm not sure why you're seeing them now.
On Mon, Apr 21, 2003 at 06:53:53PM +0300, Timo Sirainen wrote:
On Mon, 2003-04-21 at 17:47, Mark E. Mallett wrote:
A couple of notes about quotas-- I know this has been brought up before but the negative effects that occur when a user is over quota are still disconcerting.
Ideally it would be best if a user could at least delete mail when in an over-quota condition. One would think it would be enough to simply ignore errors creating the index files (and use an in-memory index). However, another problem is that the mere renaming of a file from the new/ directory to the cur/ directory can cause an over-quota error if the cur/ directory has to be expanded. We see these errors in the maillog followed by an "I/O leak" message, e.g.:
Hmm. I'm not sure how to fix this properly. I can of course just ignore those files in new/, but then user can't delete those messages. Maybe I should allow keeping the files in new/ in out-of-disk-space conditions..
I would think so. If a file can't be renamed to cur/ because of expanding the directory, there are already a bunch of files in cur/ . Allowing some deletion would help before they have to pick up the phone and have somebody intervene.
uidlist file is also problematic. If there's no disk space to build new one, the UIDs can't be permanently saved. Or worse, they could be reused for different messages breaking client's cache.
Yeah- trouble is if there are quotas enabled at all, people are going to hit them. The first time a person gets over quota they are either going to learn to manage the mailbox, or they are going to request (and probably get) more space if they have a real need for it. However it's likely to keep happening.
Unfortunately using filesystem quotas for mailboxes has problems. At one point we had a mail delivery quota system here that was not related to filesystem quotas (i.e. the mail delivery agent would arrange not to deliver mail to a mailbox that was at its limit, and would in fact insert a single warning note instead)-- however filesystem quotas were not in effect, so it was possible to manipulate the mailbox via the POP or IMAP interface. This was under sendmail, though, and I have not yet thought about doing something similar under qmail.
mm
On Mon, 2003-04-21 at 10:03, Mark E. Mallett wrote:
Unfortunately using filesystem quotas for mailboxes has problems. At one point we had a mail delivery quota system here that was not related to filesystem quotas (i.e. the mail delivery agent would arrange not to deliver mail to a mailbox that was at its limit, and would in fact insert a single warning note instead)-- however filesystem quotas were not in effect, so it was possible to manipulate the mailbox via the POP or IMAP interface. This was under sendmail, though, and I have not yet thought about doing something similar under qmail.
I don't suppose you could share how you built or where you found the system that could do mail quotas with sendmail? Thanks!
-- Mike Machado mike@innercite.com InnerCite Inc. Engineering Director / CTO
On Mon, Apr 21, 2003 at 10:15:56AM -0700, Mike Machado wrote:
On Mon, 2003-04-21 at 10:03, Mark E. Mallett wrote:
Unfortunately using filesystem quotas for mailboxes has problems. At one point we had a mail delivery quota system here that was not related to filesystem quotas (i.e. the mail delivery agent would arrange not to deliver mail to a mailbox that was at its limit, and would in fact insert a single warning note instead)-- however filesystem quotas were not in effect, so it was possible to manipulate the mailbox via the POP or IMAP interface. This was under sendmail, though, and I have not yet thought about doing something similar under qmail.
I don't suppose you could share how you built or where you found the system that could do mail quotas with sendmail? Thanks!
It was some hackery that I performed on mail.local under bsdi. I regret that it's no longer available.
"not related to filesystem quotas" was a simplification- it would actually look at filesystem quotas and use the user's soft limit if one was set, but otherwise would impose a default maximum. Most users were left with quota not set.
It also required some minimal hacking to sendmail to recognize a special return code from mail.local .
Considering that sendmail and mail.local used /var/spool/mail mailboxes, it was pretty easy to understand and manage this kind of quota. With maildirs integrated into home directories, it's not quite as simple.
mm
participants (3)
-
Mark E. Mallett
-
Mike Machado
-
Timo Sirainen