On Wed, Feb 14, 2018 at 10:42 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > On 14 Feb 2018, at 10:29, Trond Myklebust wrote: >> On Wed, 2018-02-14 at 10:21 -0500, Jeff Layton wrote: >>> On Wed, 2018-02-14 at 10:05 -0500, Benjamin Coddington wrote: >>>> Hi Olga, >>>> >>>> On 13 Feb 2018, at 15:08, Olga Kornievskaia wrote: >>>> >>>>> On Mon, Nov 14, 2016 at 11:19 AM, Trond Myklebust >>>>> <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >>>>> ... >>>> Ah, good question there.. Even though the stateid is not useful >>>> for >>>> operations that follow, I think the sequenceid should be >>>> incremented because >>>> the CLOSE is an operation that modifies the set of locks or state: >>>> >>> >>> It doesn't matter. > > Yes, good condensed point. It doesn't matter. > >>>> ... >> Is there a proposal to change the current client behaviour here? As far >> as I can tell, the answer is "no". Am I missing something? > > Not that I can see. I think we're just comparing linux and netapp server > behaviors.. > > Ben I just found very surprising that in nfs4_close_done() which calls eventually calls nfs_clear_open_stateid_locked() we change the state based on the stateid received from the CLOSE. nfs_clear_open_stateid_locked() is only called from nfs4_close_done() and no other function. I guess I'm not wondering if we had this problem described in this patch of the delayed CLOSE, if we didn't update the state after receiving the close... (so yes this is a weak proposal). -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
