On May 25, 2007, at 11:22 AM, Roch Bourbonnais wrote:
Le 22 mai 07 à 01:11, Nicolas Williams a écrit :
On Mon, May 21, 2007 at 06:09:46PM -0500, Albert Chin wrote:
But still, how is tar/SSH any more multi-threaded than tar/NFS?
It's not that it is, but that NFS sync semantics and ZFS sync
semantics
conspire against single-threaded performance.
Hi Nic, I don't agree with the blanket statement. So to clarify.
There are 2 independant things at play here.
a) NFS sync semantics conspire againts single thread performance
with any backend filesystem.
However NVRAM normally offers some releaf of the issue.
b) ZFS sync semantics along with the Storage Software + imprecise
protocol in between, conspire againts ZFS performance
of some workloads on NVRAM backed storage. NFS being one of the
affected workloads.
The conjunction of the 2 causes worst than expected NFS perfomance
over ZFS backend running __on NVRAM back storage__.
If you are not considering NVRAM storage, then I know of no ZFS/NFS
specific problems.
Issue b) is being delt with, by both Solaris and Storage Vendors
(we need a refined protocol);
Issue a) is not related to ZFS and rather fundamental NFS issue.
Maybe future NFS protocol will help.
Net net; if one finds a way to 'disable cache flushing' on the
storage side, then one reaches the state
we'll be, out of the box, when b) is implemented by Solaris _and_
Storage vendor. At that point, ZFS becomes a fine NFS
server not only on JBOD as it is today , both also on NVRAM backed
storage.
I will add a third category, response time of individual requests.
One can think of the ssh stream of filesystem data as one large remote
procedure call that says "put this directory tree and contents on
the server". The time it takes is essentially the time it takes
to transfer the filesystem data. The latency on the very last of the
request, amortized across the entire stream is zero.
For the NFS client, there is response time injected at each request
and the best way to amortize this is through parallelism and that is
very difficult for some applications. Add the items in a) and b) and
there is a lot to deal with. Not insurmountable but it takes a little
more effort to build an effective solution.
Spencer
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
