Andrew Gallatin wrote:
Rao Shoaib writes:
> Darren Reed wrote:
> > On the topic of zero-copy, what do we currently do with NFS and what
> > can we do?
> >
> > For example, will the NFS code be able to read data from disk into a
> > buffer that can be attached to an mblk and sent out, without requiring
> > any copying?
>
> This is possible even today using desballoca. sendfile uses this.
But does NFS also use it, or does NFS do a copy?
NFS does not use this.
What are the NFS semantics for a file changing as it is read? Let's
say client A requests a read of 8192 bytes from offset 0 in a file,
and an "instant" later, client B writes 8192 bytes at offset 0 of the
same file. Do the read and write simply race with each other?
I assume there must be a reader/writer lock around that file on the
NFS server, or those blocks at least, and the write has to wait for
the read to complete before it can upgrage the lock to exclusive
access. Is this true?
Yes.
If there is a reader/writer lock, what are the implications of waiting
a "long time" for the network send to complete if zero-copy is done
by NFS, rather than nearly instantly if the data is bcopied?
This is one of the reasons NFS does not use this approach. Infact
desballoca was implemented specifcially for NFS so that the buffer is
freed right away as opposed to esballoca which delays the freeing of the
buffer. However we ran into a file corruption issue. It turns out some
NIC drivers (do not remember which) wrote on the mblks.
BTW I am not convinced that zero copy is always necessary. When I was
doing NFS performance in Solaris 8/9 time frame (pre fire engine) I
coded an nfs server where there was no copy i.e the read and write on
the server were no-ops. I did not see any performance gain as the
network and cpu were the bottleneck. That could have changed now with
faster networking and CPU's but than the copying is also much faster today.
Rao.
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
