Weird Linux - FreeBSD/ZFS NFSv4 interoperability problem

Terry Kennedy TERRY at tmk.com
Mon Sep 13 02:28:06 UTC 2010


> > 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 at tmk.com             New York, NY USA


More information about the freebsd-fs mailing list