dovecot - Apr 2003 - quotas again

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.