NFS against UDP
leonp at plris.com
Wed May 6 11:46:21 UTC 2009
On Wednesday May 6 2009, Till Straumann wrote:
> A few hints (NFS read operation only; write is very similar)
> - rtems NFS implementation is fully synchronous (no read-ahead,
> i.e., request block X, wait until block X received). Probably your
> raw UDP communication is similar but if it does implement
> read-ahead / caching then expect significant slowdown when
> using NFS.
Thanks for the tip, I shall take this into account.
But most of the time we do writing, not reading...
> - For every block read, NFS requires XDR-decoding a protocol
> header. This overhead is relatively small, especially if a large
> block size is used (you want 8k / max. allowed by UDP). A large
> block size also speeds up synchronous operation.
Yes, but as i was able to understand from the last e-mails on the list, the
Jumbo packets are not supported "out-of-the-box" today. Or am I wrong?
> - The payload data is copied verbatim (w/o any byte-swapping
> to the user's buffer). If the 'xdr_mbuf' stream is used then
> the cost is similar to using normal UDP (copying from mbufs
> into user buffer) -- otherwise data are copied twice (from
> mbufs to NFS memory buffer, then again from there to user
> The behavior is compile-time configurable (nfsclient/src/rpcio.c)
> -- by default a second copy operation is avoided.
Great. Where can I read about all this?
> -> If you use a large block size, read relatively large files
> (>> NFS protocol header) and your current implementation
> does not implement read-ahead/caching then I'd be surprised
> if NFS is a lot slower. Nevertheless, you want to run a few
Can you say something about "writes"? I suppose the same, yes?
The last question - I need to be the NFS server (not client). Can you
recommend something for this?
Till, thank you very much for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users