Heiko Schlittermann writes:
Hello Sam,thank you for the clarification, I'll try to follow it ☺ But … Sam Varshavchik <mr...@courier-mta.com> (Sat Mar 12 03:32:45 2011): > Heiko Schlittermann writes: > > >Hello, > > > >the rules about calculating the maildirsize file contain a very last > >step: if there was a race condition (maildir changes during the > >recalculation), then return the calculated size, but remove remove the > >maildirsize file. > > > >Now I'm sitting in front of maildir/maildirquota.c around line 512.> >There the tmp maildirsize file gets renamed to maildirsize. Around line 550> >the check for the race condition is done. But I do not see, how the > >newly created maildirsize file gets deleted. > > > >I'm I stupid or just blind? > > The key code path is maildir_quota_add_start(), the code path that > modifies the existing quota. > > Note that when the aforementioned race condition gets detected, > recalculation_needed is set to 1, and errno is set to EAGAIN. > > Note the outer loop in maildir_quota_add_start() that invokes > maildir_checkquota again if errno is EAGAIN. Up to five times. If > the race condition gets hit five times in a row, we just throw our > hands up, and give up. > > On the next call to maildir_checkquota, because recalculation_needed > is 1, we attempt to add everything up again, which writes out a new > maildirsize file, and deletes the existing one. > > The maildirsize file does not actually get deleted. It cannot be > physically deleted, because it defines the maildir's quota. Rather, > it gets forcibly recalculated, and a new one gets written out and > renamed again. When I follow the *rules* for recalculation, there is the chance of removing the maildirsize file. And this actually happens on a system experiencing massive parallel delivery. Thus it can't be used as a reliable source for the current quota setting. The reason for investigating it is that our MTA *removes* the maildirsize file as soon as faced with a race condition during the recalculation process. And I'd say, it is according the rules on http://www.courier-mta.org/imap/README.maildirquota.html, [Calculating maildirsize, /4/.
Yes, but keep reading the next section, the very first paragraph:1. If maildirsize *does not exist*, or if its size is at least 5120 bytes, recalculate it using the procedure defined above, and use the recalculated numbers. Otherwise, read the contents of maildirsize, and add up the totals.
Therefore, after maildirsize is removed, it gets recreated from scratch at the next opportunity to do so. Because it does not exist.
Another thing, note that if the maildirsize does not exist, this means that no quota is defined for that maildir, so an implementation cannot really remove the maildirsize for a prolonged interval, because that disables the quota mechanism completely. This is fine, as stated the quota mechanism is not 100% foolproof, but a tradeoff to keep the overall overhead to an absolute minimum, while doing a reasonable guesstimate most of the time.
I do not see an interoperability issue with either approach, whether the maildirsize file gets removed, then recreated from scratch, or whether it is recreated without being removed. I'll add a note that either alternative is acceptable.
pgpxX5RONOksC.pgp
Description: PGP signature
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
