Am 20.01.2012 01:13, schrieb Timo Sirainen: > On 20.1.2012, at 1.51, Stan Hoeppner wrote: > >> I spent a decent amount of time last night researching the NFS cache >> issue. It seems there is no way to completely disable NFS client >> caching (in lie of rewriting the code oneself--a daunting tak), which >> would seem to be the real solution to the mdbox index corruption problem. >> >> So I went looking for alternatives and came up with the idea above. >> Obviously it's far from an optimal solution and introduces some >> limitations, but I thought it was worth tossing out for discussion. > > I spent months looking into NFS related issues. I read through Linux and > FreeBSD kernel source codes to figure out if there's something I could do to > avoid the problems I see. I sent some patches to try to improve things, which > of course didn't get accepted (some alternative ways might have been, but it > would have required much more work from my part). The mail_nfs_* settings are > the result of what I found out. They don't fully work, so I gave up. > >> Timo, it seems that when you designed mdbox you didn't have NFS based >> clusters in mind. Do you consider mdbox simply not suitable for such an >> NFS cluster deployment? If one has no choice but an NFS cluster >> architecture, what Dovecot mailbox format do you recommend? Stick with >> maildir? > > In the typical random-access NFS setup I don't consider any of Dovecot's > formats suitable. Not maildir, not dbox. Perhaps in future I can redesign > everything in a way that just happens to work well with all kinds of NFS > setups, but I don't really hold a lot of hope for that. It seems that either > you'll get bad performance (I'm not really interested in making Dovecot do > that) or you'll use such a setup where you get good performance by avoiding > the NFS problems. > > There are several huge Dovecot+NFS setups. They use director. It works well > enough (and with the recent fixes, I'd hope perfectly). > >> In this case the OP has Netapp storage. Netapp units support both NFS >> exports as well as iSCSI LUNs. If the OP could utilize iSCSI instead of >> NFS, switching to GFS2 or OCFS, do you see these cluster filesystem as >> preferable for mdbox? > > I don't have personal experience with cluster filesystems in recent years > (other than glusterfs, which had some problems, but most(/all?) were fixed > already or are available from their commercial support..). Based on what I've > heard, I'm guessing they work better than random-access-NFS, but even if > there are no actual corruption problems, it sounds like their performance > isn't very good.
for info i have 3500 users behind keepalived loadbalancers with drbd ocfs2 on two lucid servers, they are heavy penetrated by pop3 with maildir on dove2 , in the begin i had some performance problem but they were mostly related to the raid controlers io, so imap was very slow. Fixing this raid problems gave good imap performance now ( beside some dovecot and kernel tuneups ), anyway i would overthink this whole setup again going up to more users i.e i guess mixing loadbalancers and directors is no problem, maildir seems to be slow by io in design , so mdbox might better, and after all i would more investigate about drbd and compare gfs ocfs and other cluster filesystems better, i.e switching to iSCSI i.e i think it should be poosible to design partitioning with ldap or sql to i.e split up heavy and big mailboxes in seperate storage partitions etc am i right here Timo ? anyway i would like to test some cross hostingplace setup with i.e glusterfs lustre etc to get more knowledge as base of a multi redundant mailsystem -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
