From rsb@sac.sfbay.sun.com Fri Aug 28 14:07:07 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7SL77J7007477 for ; Fri, 28 Aug 2009 14:07:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7SL73oB032213; Fri, 28 Aug 2009 15:07:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP300103UNT1W00@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 14:07:05 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP300J1GUNSG640@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 14:07:04 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7SL74sm029647; Fri, 28 Aug 2009 14:07:04 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7SL73GC007472; Fri, 28 Aug 2009 14:07:03 -0700 (PDT) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7SL73s2007468; Fri, 28 Aug 2009 16:07:03 -0500 (CDT) Date: Fri, 28 Aug 2009 16:07:03 -0500 (CDT) From: Rich.Brown@sun.com Subject: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] To: PSARC-ext@sun.com Cc: Bill.Baker@sun.com, Rich.Brown@sun.com Message-id: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3119 I'm sponsoring this case for Bill Baker of the NFS team. This case proposed enabling technology for a forthcoming closed case. The timer expires on Friday, September 4, 2009. This case requests minor binding. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: nfs4_fid() 1.2. Name of Document Author/Supplier: Author: Bill Baker 1.3 Date of This Document: 28 August, 2009 4. Technical Description Historically, the NFSv4 client has not implemented the VOP_FID() function due to fundamental limitations of the protocol. The client cannot construct a file identifier which can be used to reactivate a vnode (via VFS_VGET()) which is usable in all cases. In particular, volatile file handle recovery as well as handling VOP_OPEN() is impossible without the additional information which is created and maintained by the NFSv4 client during VOP_LOOKUP(). Vnodes activated via VFS_VGET() may not have this information, nor can it be constructed. Given these limitations, the current nfs4_fid() simply returns EREMOTE. However, having nfs4_fid() return a file id can be useful in a very narrow, controlled context. This file ID can be used as an opaque cookie which can be compared to file IDs from other vnodes from the same vfs. This could be used by a file tree walking program to determine if a newly looked up file had been discovered previously since, by definition, the file handle uniquely identifies a different file in the protocol. This ID is persistent (assuming the server is using persistent file handles) and is therefore durable and reliable across reboots of both the client and server. The consumer of this ID can write it to stable storage and safely recover its state even after a client reboot. Therefore, nfs4_fid() is reimplemented to return the client file handle from the rnode as a file ID, solely for the purpose of doing this equivalency comparison. nfs4_vget() will not honor this file ID, meaning that it can ONLY be used in this manner, it cannot be used to activate a vnode. Since this new behavior may expose existing subsystems, like cachefs, to new failure modes, nfs4_fid() will only return a file ID when the client file system is mounted with "-o fid". By default, the option is off and the NFSv4 client will retain its current behavior. Ideally, this mount option is only used by system components which wish to use the file ID for identification as described above. Other uses are not supported. The option will NOT be documented, due to its limited utility. |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Consolidation |This | -o fid |Private |Document | new option to | | | mount_nfs | | | 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@sun.com Fri Aug 28 14:30:01 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7SLU0Rj007954 for ; Fri, 28 Aug 2009 14:30:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7SLTpNe006122; Fri, 28 Aug 2009 22:29:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP300201VPXSZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 14:29:57 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP300JM9VPWGH50@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 14:29:56 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7SLQV29005972; Fri, 28 Aug 2009 16:26:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7SLQVWZ005971; Fri, 28 Aug 2009 16:26:31 -0500 (CDT) Date: Fri, 28 Aug 2009 16:26:31 -0500 From: Nicolas Williams Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Bill.Baker@sun.com Message-id: <20090828212631.GY1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2343 On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown@Sun.COM wrote: > However, having nfs4_fid() return a file id can be useful in a very > narrow, controlled context. This file ID can be used as an opaque > cookie which can be compared to file IDs from other vnodes from the > same vfs. This could be used by a file tree walking program to > determine if a newly looked up file had been discovered previously > since, by definition, the file handle uniquely identifies a different > file in the protocol. This ID is persistent (assuming the server is > using persistent file handles) and is therefore durable and reliable That's a big assumption. There was a thread recently on nfs-discuss about adding server support for volatile file handles, for use with FUSE filesystems that lack persistent file IDs. I think that would be very useful. But even beyond that, volatile filehandles are in there to help cope with filesystems such as FAT, where no persistent file IDs exist, and so existing servers may very well be using volatile filehandles. > across reboots of both the client and server. The consumer of this ID > can write it to stable storage and safely recover its state even after > a client reboot. Doesn't sound right to me. But then, this: > Therefore, nfs4_fid() is reimplemented to return the client file handle > from the rnode as a file ID, solely for the purpose of doing this > equivalency comparison. nfs4_vget() will not honor this file ID, > meaning that it can ONLY be used in this manner, it cannot be used to > activate a vnode. limits the damage that one could do by persistently storing volatile FIDs. > Since this new behavior may expose existing subsystems, like cachefs, > to new failure modes, nfs4_fid() will only return a file ID when the > client file system is mounted with "-o fid". By default, the option is > off and the NFSv4 client will retain its current behavior. > > Ideally, this mount option is only used by system components which wish > to use the file ID for identification as described above. Other uses > are not supported. The option will NOT be documented, due to its > limited utility. It might be better if there was a way for the VOP to indicate that the returned FID is volatile. Maybe a pathconf that looks at the per-filesystem fh_expire_type attribute? Nico -- From Bill.Baker@sun.com Fri Aug 28 14:34:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7SLYEEX008121 for ; Fri, 28 Aug 2009 14:34:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7SLYAcZ012070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 29 Aug 2009 05:34:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP300D01VWY0E00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Aug 2009 14:34:10 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP3008ZTVWY8D20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Aug 2009 14:34:10 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7SLYAt9001008 for ; Fri, 28 Aug 2009 21:34:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP300K00UUS7T00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Aug 2009 15:34:10 -0600 (MDT) Received: from bill-bakers-macbook-pro-2.local ([unknown] [69.150.56.207]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP30013AVWNKY10@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Aug 2009 15:33:59 -0600 (MDT) Date: Fri, 28 Aug 2009 16:33:59 -0500 From: Bill Baker Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <20090828212631.GY1033@Sun.COM> Sender: Bill.Baker@sun.com To: Nicolas Williams Cc: Rich.Brown@sun.com, PSARC-ext@sun.com Message-id: <4A984D47.2040204@Sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> <20090828212631.GY1033@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 2541 This interface will not return a volatile file handle, period, ever. Nicolas Williams wrote: > On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown@Sun.COM wrote: >> However, having nfs4_fid() return a file id can be useful in a very >> narrow, controlled context. This file ID can be used as an opaque >> cookie which can be compared to file IDs from other vnodes from the >> same vfs. This could be used by a file tree walking program to >> determine if a newly looked up file had been discovered previously >> since, by definition, the file handle uniquely identifies a different >> file in the protocol. This ID is persistent (assuming the server is >> using persistent file handles) and is therefore durable and reliable > > That's a big assumption. There was a thread recently on nfs-discuss > about adding server support for volatile file handles, for use with FUSE > filesystems that lack persistent file IDs. I think that would be very > useful. But even beyond that, volatile filehandles are in there to help > cope with filesystems such as FAT, where no persistent file IDs exist, > and so existing servers may very well be using volatile filehandles. > >> across reboots of both the client and server. The consumer of this ID >> can write it to stable storage and safely recover its state even after >> a client reboot. > > Doesn't sound right to me. But then, this: > >> Therefore, nfs4_fid() is reimplemented to return the client file handle >> from the rnode as a file ID, solely for the purpose of doing this >> equivalency comparison. nfs4_vget() will not honor this file ID, >> meaning that it can ONLY be used in this manner, it cannot be used to >> activate a vnode. > > limits the damage that one could do by persistently storing volatile > FIDs. > >> Since this new behavior may expose existing subsystems, like cachefs, >> to new failure modes, nfs4_fid() will only return a file ID when the >> client file system is mounted with "-o fid". By default, the option is >> off and the NFSv4 client will retain its current behavior. >> >> Ideally, this mount option is only used by system components which wish >> to use the file ID for identification as described above. Other uses >> are not supported. The option will NOT be documented, due to its >> limited utility. > > It might be better if there was a way for the VOP to indicate that the > returned FID is volatile. Maybe a pathconf that looks at the > per-filesystem fh_expire_type attribute? > > Nico -- Bill Baker, 512-401-1081, x64081 From Darren.Moffat@sun.com Tue Sep 1 01:49:50 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n818noFw011657 for ; Tue, 1 Sep 2009 01:49:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n818nmX3029110 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 01:49:50 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPA00L2FB71OT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 02:49:49 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPA00JDMB70BU30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 02:49:48 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n818nkI4022060 for ; Tue, 01 Sep 2009 08:49:47 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPA000009DCMD00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 09:49:36 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPA0025WB6HN490@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 09:49:29 +0100 (BST) Date: Tue, 01 Sep 2009 09:49:28 +0100 From: Darren J Moffat Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Bill.Baker@sun.com Message-id: <4A9CE018.5090002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 494 Rich.Brown@Sun.COM wrote: > Since this new behavior may expose existing subsystems, like cachefs, > to new failure modes, nfs4_fid() will only return a file ID when the > client file system is mounted with "-o fid". By default, the option is > off and the NFSv4 client will retain its current behavior. Cachefs is already EOF and was never supported with NFSv4 so if that is the only subsystem that is potentially impacted then "-o fid" should probably be the default. -- Darren J Moffat From Bill.Baker@sun.com Wed Sep 2 08:02:17 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82F2G6d004409 for ; Wed, 2 Sep 2009 08:02:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82F29MU000702 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 08:02:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00227N3R5600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:02:15 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00MBQN3PV020@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:02:13 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82F2CFk006531 for ; Wed, 02 Sep 2009 15:02:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00M00M36VL00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:02:12 -0600 (MDT) Received: from dhcp12-238-26-248.whcs.den.wayport.net ([unknown] [129.153.214.75]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00H1ZN3MP380@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:02:10 -0600 (MDT) Date: Wed, 02 Sep 2009 10:02:09 -0500 From: Bill Baker Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <4A9CE018.5090002@Sun.COM> Sender: Bill.Baker@sun.com To: Darren J Moffat Cc: Rich.Brown@sun.com, PSARC-ext@sun.com Message-id: <4A9E88F1.1010003@Sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> <4A9CE018.5090002@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 879 Darren J Moffat wrote: > Rich.Brown@Sun.COM wrote: >> Since this new behavior may expose existing subsystems, like >> cachefs, to new failure modes, nfs4_fid() will only return a file >> ID when the client file system is mounted with "-o fid". By >> default, the option is off and the NFSv4 client will retain its >> current behavior. > > Cachefs is already EOF and was never supported with NFSv4 so if that > is the only subsystem that is potentially impacted then "-o fid" > should probably be the default. > I am strongly against making this the default. The change I've proposed, while interesting in a narrow case, is still an incomplete implementation of the architected VOP_FID/VFS_VGET protocol. Therefore, to limit the exposure of this behavior, I propose that it is only present when specifically requested, not by default. -- Bill Baker, 512-401-1081, x64081 From Darren.Moffat@sun.com Wed Sep 2 08:04:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82F4BcE019563 for ; Wed, 2 Sep 2009 08:04:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82F45cN004042 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 08:04:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC0022HN6XC100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:04:09 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00MO5N6WVG20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:04:09 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82F48p8006217 for ; Wed, 02 Sep 2009 15:04:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00B00MISA700@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 16:03:59 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00LCHN6CKZ60@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 16:03:53 +0100 (BST) Date: Wed, 02 Sep 2009 16:03:47 +0100 From: Darren J Moffat Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <4A9E88F1.1010003@Sun.com> Sender: Darren.Moffat@sun.com To: Bill Baker Cc: Rich.Brown@sun.com, PSARC-ext@sun.com Message-id: <4A9E8953.1000605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> <4A9CE018.5090002@Sun.COM> <4A9E88F1.1010003@Sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 919 Bill Baker wrote: > Darren J Moffat wrote: >> Rich.Brown@Sun.COM wrote: >>> Since this new behavior may expose existing subsystems, like >>> cachefs, to new failure modes, nfs4_fid() will only return a file >>> ID when the client file system is mounted with "-o fid". By >>> default, the option is off and the NFSv4 client will retain its >>> current behavior. >> >> Cachefs is already EOF and was never supported with NFSv4 so if that >> is the only subsystem that is potentially impacted then "-o fid" >> should probably be the default. >> > > I am strongly against making this the default. The change > I've proposed, while interesting in a narrow case, > is still an incomplete implementation of the architected > VOP_FID/VFS_VGET protocol. Therefore, to limit the > exposure of this behavior, I propose that it is only > present when specifically requested, not by default. Fair enough. -- Darren J Moffat From Rich.Brown@Sun.COM Wed Sep 2 10:30:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82HUCVw002647 for ; Wed, 2 Sep 2009 10:30:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82HU3x5028946 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 10:30:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00G0FTYCXG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 11:30:12 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00GGITYBJ800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 11:30:11 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82HUBqX018020 for ; Wed, 02 Sep 2009 17:30:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00000TSDCY00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 11:30:11 -0600 (MDT) Received: from [129.147.9.28] ([unknown] [129.147.9.28]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC005TYTYBFF00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 11:30:11 -0600 (MDT) Date: Wed, 02 Sep 2009 12:30:10 -0500 From: Rich Brown Subject: Re: nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009] In-reply-to: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> Sender: Rich.Brown@Sun.COM To: PSARC-ext@Sun.COM Cc: Bill.Baker@Sun.COM, Rich.Brown@Sun.COM Message-id: <4A9EABA2.5000204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908282107.n7SL73s2007468@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 57 This case was approved in today's PSARC meeting. Rich