From owner-freebsd-fs@FreeBSD.ORG Mon Sep 13 02:28:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3BF106579B for ; Mon, 13 Sep 2010 02:28:06 +0000 (UTC) (envelope-from TERRY@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 785418FC12 for ; Mon, 13 Sep 2010 02:28:06 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NRTG0OUH9C0022AD@tmk.com> for freebsd-fs@freebsd.org; Sun, 12 Sep 2010 22:28:01 -0400 (EDT) Date: Sun, 12 Sep 2010 22:21:16 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Sun, 12 Sep 2010 11:28:08 -0400 (EDT)" <954605288.782335.1284305288639.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem Message-id: <01NRTGJQPS9S0022AD@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <01NRSE7GZJEC0022AD@tmk.com> Cc: freebsd-fs@freebsd.org Subject: Re: Weird Linux - FreeBSD/ZFS NFSv4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 02:28:06 -0000 > > Now, let's try the newnfs client (cache should have been primed by the > > first run, so we'd expect this to be faster): > > Just thought I'd mention that, since it is a different mount, the caches > won't be primed, which is good, because that would mask differences. I was referring to the cache on the server side. While that disk subsys- tem is fast (about 600MB/sec sustained), the test locally on that server reported about 4GB/sec. > Ok, good. You aren't seeing what the two guys reported (they were really > slow, at less than 2Mbytes/sec). If you would like to, you could try the > following, since the two clients use different default r/w sizes. > > # mount -t newnfs -o nfsv3,rsize=32768,wsize=32768 new-rz1:/data /foo > > and see how it changes the read rate. I don't know why there is a > factor of 2 difference (if it isn't the different r/w size), but it > will probably get resolved as I bring the experimental client up to date. Not so good: (0:18) new-gate:/foo/Backups/Suzanne VAIO# dd if=0cff3d7b_VOL.spf of=/dev/null bs=1m 6010+1 records in 6010+1 records out 6301945344 bytes transferred in 159.656789 secs (39471828 bytes/sec) Caching seems to help: (0:19) new-gate:/foo/Backups/Suzanne VAIO# dd if=0cff3d7b_VOL.spf of=/dev/null bs=1m 6010+1 records in 6010+1 records out 6301945344 bytes transferred in 4.456822 secs (1413999810 bytes/sec) Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA