Re: Cyrus, NFS and mail spools
On Tue, 07 Sep 2004 09:10:59 -0600 "Terry.Poperszky" <[EMAIL PROTECTED]> wrote: > With Courier, I have the ability to spread access to the mail spool > directory across several incoming smtp servers, is Cyrus able to do > something similar? What I am referring too, is having multiple incoming > email servers, with their mail spools being NFS mounts to a single box > using Maildir format, access to which is served by courier Imap. This > configuration belongs to a local ISP and I am looking at porting it to > my corporate network, but I want to look at other options than Courier. With cyrus 2.3 branch in CVS it *might* be possible to store mails themselves on the NFS. The problematic part with NFS are indexes and locking they need; in 2.3 branch indexes can be split to a separate "metadata" partition which can be local. Of course this still does not bring you the possibility of many cyrus instances on separate machines using the same mail spool over NFS. As i see it, this would still require some established mechanism to update indexes on all machines in a consistent manner. One of the possibilities is to just rebuild them when they not match the actual state of the mailbox, as i understand the Dovecot is doing. How costly would that be in terms of I/O and/or cpu? Ken, comments? -- Jure Peèar --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus, NFS and mail spools
Jure PeÃar wrote: On Tue, 07 Sep 2004 09:10:59 -0600 "Terry.Poperszky" <[EMAIL PROTECTED]> wrote: With Courier, I have the ability to spread access to the mail spool directory across several incoming smtp servers, is Cyrus able to do something similar? What I am referring too, is having multiple incoming email servers, with their mail spools being NFS mounts to a single box using Maildir format, access to which is served by courier Imap. This configuration belongs to a local ISP and I am looking at porting it to my corporate network, but I want to look at other options than Courier. With cyrus 2.3 branch in CVS it *might* be possible to store mails themselves on the NFS. The problematic part with NFS are indexes and locking they need; in 2.3 branch indexes can be split to a separate "metadata" partition which can be local. Of course this still does not bring you the possibility of many cyrus instances on separate machines using the same mail spool over NFS. As i see it, this would still require some established mechanism to update indexes on all machines in a consistent manner. One of the possibilities is to just rebuild them when they not match the actual state of the mailbox, as i understand the Dovecot is doing. How costly would that be in terms of I/O and/or cpu? As far as I'm concerned, NFS still is not an option for Cyrus for all of the reasons that have been outlined in the past. Cyrus 2.3 *might* work with NFS, but I'm not making any guarantees. Cyrus *will* work with a shared filesystem on a SAN, provided it has the correct file locking and memory mapping semantics. I know that Sun's QFS and SGI's CXFS both do, I'm not sure about Redhat's GFS. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus, NFS and mail spools
Ken Murchison wrote: >As far as I'm concerned, NFS still is not an option for Cyrus for all of >the reasons that have been outlined in the past. Cyrus 2.3 *might* work >with NFS, but I'm not making any guarantees. For what it's worth, we've been running Cyrus 2.1 in production on NFS for about a year now. Approximately six Cyrus instances running under Solaris share a high-availability NetApp filler, shifting about 1TB of mail per week without problem. We had to make a few small modifications to Cyrus. I think these have all been discussed on the list at some time - things like not holding files open across rmdir calls. I would suggest the specific combination of NFS client and NFS server was important - I doubt any other combination would have been as successful. One important detail - we are using local locking (undocumented NFS mount option "llock"). When network locking is enabled (default), the Solaris NFS client disables all client-side caching of locked files, which results in excessive I/O rates. Using "llock" allows client-side caching of locked files, but makes it absolutely critical that only one Cyrus instance accesses a given volume at any time, and we go to great lengths to ensure this is the case. I'm not sure we would make the same choice again, but when project was initiated SANs were not mature enough, and we had extensive experience in running the Solaris/NetApp combination in demanding applications (among other things, a very busy multi-terabyte Oracle instance). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus, NFS and mail spools
Andrew McNamara wrote: Ken Murchison wrote: [snip] We had to make a few small modifications to Cyrus. I think these have all been discussed on the list at some time - things like not holding files open across rmdir calls. Could you elaborate more on this? I would suggest the specific combination of NFS client and NFS server was important - I doubt any other combination would have been as successful. One important detail - we are using local locking (undocumented NFS mount option "llock"). When network locking is enabled (default), the Solaris NFS client disables all client-side caching of locked files, which results in excessive I/O rates. Using "llock" allows client-side caching of locked files, but makes it absolutely critical that only one Cyrus instance accesses a given volume at any time, and we go to great lengths to ensure this is the case. I'm not sure we would make the same choice again, but when project was initiated SANs were not mature enough, and we had extensive experience in running the Solaris/NetApp combination in demanding applications (among other things, a very busy multi-terabyte Oracle instance). --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus, NFS and mail spools
Terry.Poperszky wrote: With Courier, I have the ability to spread access to the mail spool directory across several incoming smtp servers, is Cyrus able to do something similar? What I am referring too, is having multiple incoming email servers, with their mail spools being NFS mounts to a single box using Maildir format, access to which is served by courier Imap. This configuration belongs to a local ISP and I am looking at porting it to my corporate network, but I want to look at other options than Courier. Thanks Is NFS a requirement? If you need to split the SMTP part, you can run multiple instances of any SMTP server (e.g. sendmail), all of them delivering mail via LMTP to a single server running Cyrus. Cleaner, much more efficent and scalable, IMHO. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
