Date: Mon, 23 Dec 2013 13:55:49 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <52B824C5.1020804@FreeBSD.org> In-Reply-To: <20131223115055.GC59496@kib.kiev.ua> References: <201312230843.rBN8hHTx077901@svn.freebsd.org> <20131223111450.GB59496@kib.kiev.ua> <52B82017.1040706@FreeBSD.org> <20131223115055.GC59496@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23.12.2013 13:50, Konstantin Belousov wrote: > 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 file during >>>> RPC thread affitinity handling, use trivial hash of the full file handle. >>>> ZFS's struct zfid_short does not have padding field after the length field, >>>> as result, originally picked 8 bytes are loosing lower 16 bits of object ID, >>>> causing many false matches and unneeded requests affinity to same thread. >>>> This fix substantially improves NFS server latency and scalability 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 ? >> >> Yes, I did a tree search and in all found cases the structure was >> pre-erased. > I.e. you checked all in-tree VOP_VPTOFH implementations, right ? I checked all call places of VOP_VPTOFH and VOP_FID in a tree. As I can see these structures are normally pre-erased by callers. >>> Also, this constitues subtle VFS KBI change. >> >> In what way it touched VFS KBI? I indeed modified RPC FHA KPI to make it >> more safe, but I don't see how it may touch anything else then two of >> our NFS servers. > > See above, it is now required to ensure that fid_data0 is zeroed, for > filesystems which only fill fid_data. I believe the only that really important is that NFS itself erases the structure before calling these VFS methods. But I'll recheck NFS code once more just to be sure. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52B824C5.1020804>