ctl_cyrusdb -r performance over NFS

[Andrew McNamara]

>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.

You assume I don't already know this... 8-)

BTW, I don't think it's "violate unix semantics OR pitiful perfomance" - 
the protocol is flawed in ways that make that "violate unix semantics
AND pitiful perfomance". In particular, lost, out of order or replayed
requests are not fully addressed by the stateless design.

For what it's worth, we go to extraordinary lengths to ensure only one
host hits a given NFS volume at a time, we spend silly amounts of money to
keep the latency down and the bandwidth up, and we use the best quality
NFS implementations we can.

I'm not convined that SAN (where "storage" is a euphemism for "disk") is
really the answer to anything. Network attached storage (where "storage"
is a euphemism for "file server") is a far more convenient model. We just
need a better protocol. If only Plan9 had gained a critical mass... 8-)

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/