svn commit: r259765 - in head/sys: fs/nfsserver nfs nfsserver

[Konstantin Belousov]

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 ?


> 
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20131223/206680f4/attachment.sig>