Date: Mon, 23 Dec 2013 13:50:55 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r259765 - in head/sys: fs/nfsserver nfs nfsserver Message-ID: <20131223115055.GC59496@kib.kiev.ua> In-Reply-To: <52B82017.1040706@FreeBSD.org> References: <201312230843.rBN8hHTx077901@svn.freebsd.org> <20131223111450.GB59496@kib.kiev.ua> <52B82017.1040706@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--80KblFqI5cx0eMF+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 23, 2013 at 01:35:51PM +0200, Alexander Motin wrote: > On 23.12.2013 13:14, Konstantin Belousov wrote: > > On Mon, Dec 23, 2013 at 08:43:17AM +0000, Alexander Motin wrote: > >> Author: mav > >> Date: Mon Dec 23 08:43:16 2013 > >> New Revision: 259765 > >> URL: http://svnweb.freebsd.org/changeset/base/259765 > >> > >> Log: > >> Fix RPC server threads file handle affinity to work better with ZFS. > >> > >> Instead of taking 8 specific bytes of file handle to identify fil= e during > >> RPC thread affitinity handling, use trivial hash of the full file h= andle. > >> ZFS's struct zfid_short does not have padding field after the lengt= h field, > >> as result, originally picked 8 bytes are loosing lower 16 bits of o= bject ID, > >> causing many false matches and unneeded requests affinity to same t= hread. > >> This fix substantially improves NFS server latency and scalabilit= y in SPEC > >> NFS benchmark by more flexible use of multiple NFS threads. > >> > >> Sponsored by: iXsystems, Inc. > > > > Did you audited all other filesystems to ensure that struct fid. > > fid_data0 is filled (zeroed) consistently ? >=20 > Yes, I did a tree search and in all found cases the structure was=20 > pre-erased. I.e. you checked all in-tree VOP_VPTOFH implementations, right ? >=20 > > Also, this constitues subtle VFS KBI change. >=20 > In what way it touched VFS KBI? I indeed modified RPC FHA KPI to make it= =20 > more safe, but I don't see how it may touch anything else then two of=20 > our NFS servers. See above, it is now required to ensure that fid_data0 is zeroed, for filesystems which only fill fid_data. --80KblFqI5cx0eMF+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSuCOeAAoJEJDCuSvBvK1BHfUP/0rNbkR7C3N60lPd0NAHl3Wu 19zB7p0SPtVtUmtJf5KuSQL3gSCLuKp3jeHzgGIS1+l/feL37nzRVvR91JAiFqgX krso2QQ/chgxHlAdLGgvTx7UIb1Ppbcw3LbUe2TLD54YLMSSlZ17ADsCOt3Imjcz tbZqrGH54P9GZ7lJbnNUzYrhnrSKwzRb2JHZM92N14lOCN+8vetIjI4ABkGyjBlS 9SYEdfqWCKRqKdpFaQTJ4oQDL78eLYLugHbXwVn3dgYuZGMfiTPvW20D9i+K60na LqPaMPPKkGiuZAS61Qdpo8VUiXCG6aHGfFGQOzH61X33s2iX6t1ziQnNdCCoE7uX Jtz8DdKfO7hKb9Cn4juuSz0YcjSQgReSQiE0+Lw16E8+5jovizAo5GI9X0iK+I3V ofHjQIEr7AYApSQf+fdtrVq84bq9f8DZzzAxHYlQIpz2rt8nb154RJT1wK2hnDlX 3CQJ3nQQg4snpTMGSw5VNBdAmuTfESXki0Tkgm4YKiUPR7b4pZQGWffljrVHe1i1 Z+6Nj4W/LrgBznSQ0VkiPV6aUzfgsvzwpmckul6KU+qrfhI//+32JWEH/ixXPmUa QobaO7dir0rACCMLMtgkvioVp8v14CHPEPm7T00qG8bTlcQmM5hQ2Wd8H5hY4hbd D5w5USVVFBoymosAPK2B =jvNy -----END PGP SIGNATURE----- --80KblFqI5cx0eMF+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131223115055.GC59496>