The parameters listed for nfs installations (mmap_disable, doctlock_use_excl, mail_nfs_storage, mail_nfs_index) - are they necessary for data integrity, and/or do they compensate for NFS latency and improve performance?
My understanding is the indexes are a critical part of a dbox storage, but on the other hand having local indexes is a major performance consideration. Is maildir a "better" choice under NFS than dbox?
Daniel
On 6/29/2011 1:10 PM, Daniel L. Miller wrote:
The parameters listed for nfs installations (mmap_disable, doctlock_use_excl, mail_nfs_storage, mail_nfs_index) - are they necessary for data integrity, and/or do they compensate for NFS latency and improve performance?
My understanding is the indexes are a critical part of a dbox storage, but on the other hand having local indexes is a major performance consideration. Is maildir a "better" choice under NFS than dbox?
Depends a lot on the latency and IOPS performance of the NFS server, the aggregate concurrent IMAP IO load, and also the inbound new mail delivery rate from the upstream MTA.
With either mbox or maildir you can put the indexes on fast local disk, SLC SSD being great for this, keeping a lot of random IO off the NFS server. This isn't possible with dbox storage since, as you noted, the index data is integral to the mail files. Corrupted mbox/maildir indexes are easy to fix, simply delete them and they're auto re-created.
Since maildir is IOPS heavy and NFS/GFS/OCFS don't seem to like high IOPS workloads that make heavy use of locking, mbox becomes very attractive due to it's very low IOPS demands. If you can live with the folder tree limitations of mbox, along with a higher probably of mailbox file corruption, mbox is likely the best format for NFS/GFS/OCFS.
Again, this all depends on the performance of the NFS server. If you have a properly configured NetApp filer you can probably do anything you want without limitation. If your NFS server is a home grown Linux or *BSD box that suffers high latency and/or low IOPS throughput, you're probably a good candidate for mbox and local index files.
Test such a configuration with both mbox and maildir using local indexes on fast loca disk or SSD. If you don't run out of IOPS with maildir it's probably preferable to mbox.
-- Stan
On Wed, 2011-06-29 at 18:40 -0500, Stan Hoeppner wrote:
Since maildir is IOPS heavy and NFS/GFS/OCFS don't seem to like high IOPS workloads that make heavy use of locking, mbox becomes very attractive due to it's very low IOPS demands. If you can live with the folder tree limitations of mbox, along with a higher probably of mailbox file corruption, mbox is likely the best format for NFS/GFS/OCFS.
I don't believe I just read that.
Timo I will bite my tongue, look at that the sky today is purple
On Wed, 2011-06-29 at 18:40 -0500, Stan Hoeppner wrote:
Since maildir is IOPS heavy and NFS/GFS/OCFS don't seem to like high IOPS workloads that make heavy use of locking, mbox becomes very attractive due to it's very low IOPS demands. If you can live with the folder tree limitations of mbox, along with a higher probably of mailbox file corruption, mbox is likely the best format for NFS/GFS/OCFS.
You shouldn't equate NFS with GFS/OCFS. They have very little in common. The above is more or less true for GFS/OCFS, but definitely not NFS.
On 6/29/2011 11:12 PM, Timo Sirainen wrote:
On Wed, 2011-06-29 at 18:40 -0500, Stan Hoeppner wrote:
Since maildir is IOPS heavy and NFS/GFS/OCFS don't seem to like high IOPS workloads that make heavy use of locking, mbox becomes very attractive due to it's very low IOPS demands. If you can live with the folder tree limitations of mbox, along with a higher probably of mailbox file corruption, mbox is likely the best format for NFS/GFS/OCFS.
You shouldn't equate NFS with GFS/OCFS. They have very little in common. The above is more or less true for GFS/OCFS, but definitely not NFS.
I was under the impression that some NFS server implementations don't have stellar maildir performance with Dovecot clusters due to the NFS caching problem, and locking, which is why I made the distinction between something like a NetApp and a DIY NFS server. Is this not true? Or is this NFS version dependent? Or is my recollection simply faulty?
-- Stan
On 30/06/2011 00:40, Stan Hoeppner wrote:
If you can live with the folder tree limitations of mbox
Did you mean with or without considering http://wiki2.dovecot.org/MboxChildFolders ?
Bill
On 6/30/2011 9:03 AM, William Blunn wrote:
On 30/06/2011 00:40, Stan Hoeppner wrote:
If you can live with the folder tree limitations of mbox
Did you mean with or without considering http://wiki2.dovecot.org/MboxChildFolders ?
I was referring the to the classic mbox limitation of not being able to store both email and sub folders within a given folder. If the example in wiki2 can be successfully implemented without running into any other potential problems (i.e. backup or other software that only works with the standard mbox directory layout), then the only downside to mbox would be the occasional file corruption, as demonstrated in another very recent thread.
-- Stan
On Wed, 2011-06-29 at 11:10 -0700, Daniel L. Miller wrote:
The parameters listed for nfs installations (mmap_disable, doctlock_use_excl, mail_nfs_storage, mail_nfs_index) - are they necessary for data integrity, and/or do they compensate for NFS latency and improve performance?
My understanding is the indexes are a critical part of a dbox storage, but on the other hand having local indexes is a major performance consideration. Is maildir a "better" choice under NFS than dbox?
If you have only a single Dovecot server, you don't really need to worry about anything. If you have more, use Dovecot director (with LMTP) and again you don't have to worry about anything. Any other configuration will have random errors regardless of what settings you use.
participants (5)
-
Daniel L. Miller
-
Noel Butler
-
Stan Hoeppner
-
Timo Sirainen
-
William Blunn