On Mon, May 21, 2007 at 02:55:18PM -0600, Robert Thurlow wrote:
> Albert Chin wrote:
>
> >Why can't the NFS performance match that of SSH?
>
> One big reason is that the sending CPU has to do all the comparisons to
> compute the list of files to be sent - it has to fetch the attributes
> from both local and remote and compare timestamps. With ssh, local
> processes at each end do lstat() calls in parallel and chatter about
> the timestamps, and the lstat() calls are much cheaper. I would wonder
> how long the attr-chatter takes in your two cases before bulk data
> starts to be sent - deducting that should reduce the imbalance you're
> seeing. If rsync were more multi-threaded and could manage multiple
> lstat() calls in parallel NFS would be closer.
Well, there is no data on the file server as this is an initial copy,
so there is very little for rsync to do. To compare the rsync
overhead, I conducted some more tests, using tar:
1. [copy 400MB of gcc-3.4.3 via tar/NFS to ZFS file system]
# mount file-server:/opt/test /mnt
# time tar cf - gcc343 | (cd /mnt; tar xpf - )
...
419721216 bytes in 1:08.65 => 6113928.86 bytes/sec
2. [copy 400MB of gcc-3.4.3 via tar/ssh to ZFS file system]
# time tar cf - gcc343 | ssh -oForwardX11=no file-server \
'cd /opt/test; tar xpf -'
...
419721216 bytes in 35:82 => 11717510.21 bytes/sec
3. [copy 400MB of gcc-3.4.3 via tar/NFS to Fibre-attached file system]
# mount file-server:/opt/fibre-disk /mnt
# time tar cf - gcc343 | (cd /mnt; tar xpf - )
...
419721216 bytes in 56:87 => 7380362.51 bytes/sec
4. [copy 400MB of gcc-3.4.3 via tar/ssh to Fibre-attached file system]
# time tar cf - gcc343 | ssh -oForwardX11=no file-server \
'cd /opt/fibre-disk; tar xpf -'
...
419721216 bytes in 35:89 => 11694656.34 bytes/sec
So, it would seem using #1 and #2, NFS performance can stand some
improvement. And, I'd have thought that since #2/#4 were similar,
#1/#3 should be as well. Maybe some NFS/ZFS issues would answer the
discrepancy.
I think the bigger problem is the NFS performance penalty so we'll go
lurk somewhere else to find out what the problem is.
--
albert chin ([EMAIL PROTECTED])
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
