From owner-freebsd-fs@FreeBSD.ORG Tue May 17 09:20:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BFEB1065670 for ; Tue, 17 May 2011 09:20:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBA38FC08 for ; Tue, 17 May 2011 09:20:18 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p4H9KB2t051154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 12:20:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p4H9KBDh042104; Tue, 17 May 2011 12:20:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p4H9KBnK042103; Tue, 17 May 2011 12:20:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 May 2011 12:20:11 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20110517092011.GK48734@deviant.kiev.zoral.com.ua> References: <256284561.428250.1305590315172.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tt/ITYRGFe52qw7n" Content-Disposition: inline In-Reply-To: <256284561.428250.1305590315172.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD FS Subject: Re: RFC: adding a lock flags argument to VFS_FHTOVP() for FreeBSD9 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 09:20:20 -0000 --tt/ITYRGFe52qw7n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 16, 2011 at 07:58:35PM -0400, Rick Macklem wrote: > Hi, >=20 > Down the road, I would like the NFS server to be able to do a > VFS_FHTOVP(mp, &fhp->fh_fid, LK_SHARED, vpp); > similar to what is already supported for VFS_VGET(). The reason > is that, currently, when a client does read-aheads, these reads are > basically serialized because the VFS_FHTOVP() gets an LK_EXCLUSIVE > locked vnode for each RPC on the server. >=20 > Like VFS_VGET(), the underlying file system can still choose to > return a LK_EXCLUSIVE locked vnode even when LK_SHARED is specified. > (Some file systems, such as FFS, just call VFS_VGET() in VFS_FHTOVP(), > so all that happens is that the flag is passed through to VFS_VGET() > for those ones.) Yes, the flag to specify the locking mode does only specify the minimal locking requirements, and filesystem is allowed to upgrade it to the more strict lock type. E.g. UFS would only return shared lock if the vnode was found in hash, AFAIR. If not told otherwise, getnewvnode(9) forces lockmgr to convert all lock requests into exclusive. >=20 > To minimize the risk of the patch breaking something, I have it setting > LK_EXCLUSIVE for all VFS_FHTOVP() calls so that the semantics don't > actually change. (Changing the NFS server to use LK_SHARED is a trivial > patch, but will need extensive testing, so I'm not planning on that > change for 9.0.) >=20 > If you are interested, my current patch is at: > http://people.freebsd.org/~rmacklem/fhtovp.patch >=20 > So, does this sound like a reasonable thing to commit, once the patch > is reviewed? Sure, please do it before the code slush. --tt/ITYRGFe52qw7n Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3SPcoACgkQC3+MBN1Mb4iLDgCgzybKN06HfY7h5tMg2BxX+iVh KLkAnij6Gjq5oy6+vRqQHO4ZOwHWKpBC =O73t -----END PGP SIGNATURE----- --tt/ITYRGFe52qw7n--