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
