From owner-svn-src-all@FreeBSD.ORG Mon Dec 23 11:55:56 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E599AA33; Mon, 23 Dec 2013 11:55:55 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A734167D; Mon, 23 Dec 2013 11:55:55 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id b15so2293397eek.38 for ; Mon, 23 Dec 2013 03:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FQfo+oMDNHx7w774Z35NCOfniOpMgp2S4Socnzw6ncE=; b=CGL1o7GmkDc6EZv5DIH9OoY/A/it1nfq7rBndtkEDctmXpuW/Cp3YRVY+MNXjbhIcm 11GgHOPLBlK/vnKDUm7GdbE1HV+uBKzOXyvTNhvZcxXYwByEOKomjssFlhOqSRybLfqt NB+QVyr5yGW4OYLAA2Atc94XMvwykLYN6DxUr4xPtQ2/GglRygwMiyVJgTDk09VfCvr+ Ac416VDiS7biQl/9JlBotYrYiqwbIweo0rxBZXOxnbCFpysCHOq/M77PdUDFMNzcOXXq DdhfwnfYMyoRHG/jecdB2KbLDrGOudyxTJIYd2UcGYZJuGqP/7sljlBf8cwb7rMcT+1T /8zg== X-Received: by 10.15.74.200 with SMTP id j48mr82508eey.102.1387799753491; Mon, 23 Dec 2013 03:55:53 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id a51sm44906364eeh.8.2013.12.23.03.55.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Dec 2013 03:55:52 -0800 (PST) Sender: Alexander Motin Message-ID: <52B824C5.1020804@FreeBSD.org> Date: Mon, 23 Dec 2013 13:55:49 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r259765 - in head/sys: fs/nfsserver nfs nfsserver References: <201312230843.rBN8hHTx077901@svn.freebsd.org> <20131223111450.GB59496@kib.kiev.ua> <52B82017.1040706@FreeBSD.org> <20131223115055.GC59496@kib.kiev.ua> In-Reply-To: <20131223115055.GC59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 11:55:56 -0000 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