Date: Thu, 18 Oct 2012 17:54:33 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Alexey Tyurikov <alexey.tyurikov@gmail.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: NFS using ZFS issue Message-ID: <113869727.2504027.1350597273963.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <CANJVYo%2Bvt3nk5371VB1uNxWiZdCa8jWQOKYU%2BQ%2B4O9dQN6dCKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Tyurikov wrote: First off, I hope you didn't mind me putting the cc for the mailing list back in. > The solution is very simple: use 9.1 :-) Unbelievable ... >=20 Not unbelievable at all. NFS performance is usually a function of the underlying file systems and network performance, at least in the server. (All an NFS server does is translate RPC requests into correspinding VOP_xxx() operations. Plus, there is DRC overhead, which has been discussed recently.) Btw, for everyone else, Alexey sent me some packet traces. The attributes for the broken cases (Change and Modify Time) looked fine (if those change, the client would flush its cache. All I could see is that it got to a point for ZFS where there were many outstanding Read requests without replies, although there was data (wireshark didn't recognize these as replies) flowing from server->client. I have no idea what might have caused this. One thought was a broken TSO for the server's network interface. Another was some sort of resource constraint. Very little has changed in the NFS server between 9.0 and 9.1. (You can look at http://svn.freebsd.org/base/stable/9, but you won't find much changed.) I'll take another look, but I can't think of any NFS change between 9.0 and 9.1 that could affect this. Anyhow, glad it works better for you for 9.1, although I'd like to know what was going on for ZFS for 9.0? rick >=20 > Best regards > Alexey >=20 >=20 > 2012/10/18 Alexey Tyurikov < alexey.tyurikov@gmail.com > >=20 >=20 >=20 > Hello Rick, >=20 >=20 > thank you for the tip, I'll try it. What I've already done, I've > installed a FreeBSD server on at least 5 machines including 3 virtual > machines. It always the same=C2=A0with the exception of FreeBSD 8.2 > (hardware and virtual machine) - it works. >=20 >=20 > Then I've tested different clients: > - FreeBSD Client works > - RedHat =C2=A05.6 (Tikanga) works (!) but only with NFSv3 > - CentOS 6 doesn't work > - Debian 6 doesn't work >=20 >=20 > Regarding non-closing file from capture output: the file has been > closed, it was just cut by tcpdump. You can see it in the=C2=A0 > test_zfs_2.pcap >=20 >=20 > 38546 0.490573 10.1.3.90 10.1.3.111 NFS 262 V4 Call (Reply In 38547) > CLOSE StateID:0x1fe0 > 38547 0.490759 10.1.3.111 10.1.3.90 NFS 202 V4 Reply (Call In 38546) > CLOSE >=20 >=20 > Rick, thank you for your help! I'll post my issue on=C2=A0freebsd-fs@. If > I'll find a solution, I'll let you know. >=20 >=20 > Best regards > Alexey >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 2012/10/18 Rick Macklem < rmacklem@uoguelph.ca > >=20 >=20 > Just a ranom thought. Since you still seem to have packet > loss and then there is the weird behaviour (no replies, but > data moving from server->client), it might be network > interface related. >=20 > If your network interface has TSO support, I'd try disabling > that (it has been buggy in the past). >=20 > Also, if you have a different kind (different chipset) of > network hardware, you could try switching that on the server. >=20 > Mostly though, I'll be interested to see if anyone else can > explain it, when you post it to a list (freebsd-fs@ maybe?), rick >=20 >=20 >=20 >=20 > -- > Alexey Tyurikov >=20 >=20 >=20 >=20 > -- > Alexey Tyurikov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?113869727.2504027.1350597273963.JavaMail.root>