Cyrus, NFS and mail spools

[Andrew McNamara]

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