On Thu, 13 Mar 1997, Karl Swartz wrote:
But... I've read that NFS writes are much faster in NFS v3 than v2. This, of course, leads me to my question (ta-daa) :
That's news to me, unless you're referring to the ability ot NFSv3 to use larger block sizes. For netnews, that's not likely to be of much benefit since most articles are very small.
Maybe I should add that I read this in a book about performance tuning for Solaris systems ;) But it did look as if this write performance improvement was connected to the version of the NFS protocol. Quote from 'Configuration and capacity planning for Solaris servers' by Brian Wong :
In response to a variety of technical requests from customers, the NFS protocol was revised in 1993, with the resulting protocol being designated Version 3. The new protocol is similar to its predecessor, but it makes improvements in several key areas. In particular, the new protcol implements the following changes:
- It permits write operations to be performed much more quickly through the use of a two-phase commit protocol, while still maintaining the server's stateless view of the protocol.
[ some more features cut out ]
Naturally, both the client and server systems must implement these features; since many hosts do not, some of the new features are optional and are negotiated between client and server when a file system is mounted by the client"
Is this not applicable to NetApp servers?
Unfortunately, it's the "feeder" machine (the one which is writing to the filer) that gets hit the hardest by using NFSv3. One operation that is hit particularly hard is renumbering the active file, though there are others that behave similarly.
But INND doesn't scan directories very much does it? I can imagine that the renumber operation would suffer but it doesn't do renumber all that frequently. Isn't it nnrpd that accounts for most of the readdir+ performance waste when using NFS v3?
Regards,
/Ragnar, Algonet