ctl_cyrusdb -r performance over NFS

[John Alton Tamplin]

Andrew McNamara wrote:

>>You probably don't want to be running cyrus on an NFS partition.
>>    
>>
>
>The only other option would be a SAN, and people here trust them even
>less.  BTW, they've successfully been running a large, heavily used,
>Oracle instance for several years now over NFS to a Netapp with several
>terabytes of storage, which surprised me.
>
>We're in the process of doing some agressive testing on the resulting mail
>system to find out if it corrupts messages under load, etc.
>  
>
A SAN is just a different transport mechanism between the host and the 
drives -- the protocol is the same old SCSI that has been around for 
years.  That said, there is less interoperability than one would like at 
this point.

The basic problem with NFS is that either you violate standard Unix 
filesystem semantics or you have pitiful performance (by disabling 
client-side caching).  Add to that the idea that locking was an 
after-thought (the design goal of a stateless filesystem doesn't exactly 
fit with maintaining locks) and it is really a mess.

As long as you only have one machine writing to the data, you don't have 
to worry so much about broken filesystem semantics (which is why your 
Oracle instance works), but you still have lousy performance.  Locking 
in particular is hundreds of times more painful on an NFS filesystem 
than a local one because it requires a network round-trip, XDR, etc. 
 Theoretically, if you only have one writer you could keep the locks in 
the client and avoid this performance penalty, but I am not aware of any 
such implementation.  Presumably you could hack the code to maintain its 
own locks in a shared memory segment, but it would be a lot of work and 
only useful for your particular situation.

-- 
John A. Tamplin                               Unix System Administrator
Emory University, School of Public Health     +1 404/727-9931