Joshua E Warchol writes: > On Tue, Dec 11, 2001 at 05:42:33PM -0500, Sam Varshavchik wrote: >> >The Postfix Maildir++ Quota patch does not use a maildirsize file. It uses >> >the filesize as encoded on the filename to calculate quota use. The author >> >says that a maildirsize file is not NFS safe and violates the main goals >> >of the Maildir format. Can anyone confirm this? >> >> Baloney. > > Sam, I would appreciate it if you could elaborate just a little bit. > I think that the file is "safe enough" if it is written in a careful > way. I just want to be able to implement it properly.
Well there are certainly NFS bugs here and there, but this implementation is designed to failover gracefully, and reduce the impact of NFS races to near irrelevance. It helps to understand that perfect, airtight, quota calculations on maildirs is going to involve unacceptable overhead and require all software using maildirs to incur this overhead. As the documentation states, the overall mechanism is designed to implement a best-effort, approximate, quota enforcement with negligible overhead, and graceful failover. If you want exact quota numbers, just give up and use mboxes with NFS-safe dot-lock semaphores, and accept your system performance come crashing into the basement. I believe that if you've set a 10MB quota on a mail account, you're not going to care if the maildir winds up with 10.1MB worth of mail, due to a race condition that happened at the wrong time. What you really want to do here is simply make sure something puts a cork in it before the maildir grows to 20, 50, or 100MB, and that's what you're going to get. The most frequent NFS bug is non-atomic file appends. That's probably what "not NFS-safe" means. So what will happen, if you catch the race condition, is that you're not going to account for one of the message, as the quota update for the first message will be overlayed by the quota updated for the second message. Well, the world is not going to end, because of that. It won't. The way that the maildirsize file works is that it gets completely recalculated at regular intervals, so eventually the misses are going to be caught up with. So, even if you hit that race condition, you're not going to be burned unless the race happened to also involve a 100MB message. However, if your mail quota is 10MB per mail account, your mail server should not be accepting 100MB messages in the first place. The sequence of events that must happen in order to exploit quota enforcement to any meaningful extent is not something that I'm going to lose any sleep over. There's also another race situation, with or without NFS, where quota recalculation happens while some message is in the process of being delivered, at the same time (and to be technically accurate, also if two messages are being simultaneously delivered right when the mailbox is at its quota), and the same principle applies there as well. What you get with maildirsize is a pitifully small overhead on delivering mail to maildirs, and you get in return a fairly sturdy quota enforcement that can be expected to put a lid on things if somebody gets out of line. I believe that most people will find the design tradeoffs quite acceptable. I've yet to see a single message here, or on the sqwebmail list, where someone complains that the calculated quota was off, a little bit. I'm sure that there are plenty of people who are already using maildirquotas with NFS, and I don't see them complaining. -- Sam _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
