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