Subject: [nfsv4] Should client issue close in stale fh?

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Thu, 23 Aug 2018 16:38:17 +0200 (CEST)

Hi NFSv4 gurus,

we have a following situation. A file, opened by
client-A get delete by client-B before LAYOUTGET
is called:

client-A -> server : OPEN(file)
server -> client-A : fh

client-B -> server : REMOVE(file)
server -> client-A : OK

client-A -> server : LAYOUTGET(fh)
server -> client-A : ERR_STALE

Client-A never sends close. The spec is not
clear about it. Well, I understand, that probably
if file is opened, then file handle must still be
valid, but (a) this is hard to implement for distributed
systems and (b) NFS4ERR_STALE is valid reply to
LAYOUTGET.

Thanks,
   Tigran.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 23 Aug 2018 11:29:12 -0400

> systems and (b) NFS4ERR_STALE is valid reply to

It is also a valid and indeed expected reply to PUTFH+CLOSE in that
situation, so why should the client not be allowed to optimise it away?

If the server doesn't want that to happen, then it has the option of
not actually deleting the file when it is unlinked above, and instead
waiting until the client chooses to close the file.

Cheers
  Trond

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Thu, 23 Aug 2018 22:05:04 +0200 (CEST)

I see the rational behind.But, as v4 is stateful  we will prefer that client releases the state.
this makes server logic simpler. However, even if client will start to send it, we can't expect
behavior change on your deployments. As a result, we have to handle that case on  the server.
Moreover, I would strongly suggest that 5661 and 7530 get updated to make such optimization
legal (or illegal) as 5661 talks about layoutrecall on remove, but nothing about possibly missing
close.

Thanks,
   Tigran. 

----- Original Message -----
> From: "Trond Myklebust" <[email-masked]>
> To: "Tigran Mkrtchyan" <[email-masked]>, "NFSv4" <[email-masked]>
> Sent: Thursday, August 23, 2018 5:29:12 PM
> Subject: Re: [nfsv4] Should client issue close in stale fh?

---

From: Rick Macklem <[email-masked]>
Date: Fri, 24 Aug 2018 00:39:18 +0000

Tigran wrote:
>I see the rational behind.But, as v4 is stateful  we will prefer that client releases the >state.
>this makes server logic simpler. However, even if client will start to send it, we can't >expect
>behavior change on your deployments. As a result, we have to handle that case on  >the server.
>Moreover, I would strongly suggest that 5661 and 7530 get updated to make such >optimization
>legal (or illegal) as 5661 talks about layoutrecall on remove, but nothing about >possibly missing
>close.
I think the RFCs are clear in that a current FH is a required argument for Close.
For example, from pg. 412 in RFC-5661:
   The CLOSE operation releases share reservations for the regular or
   named attribute file as specified by the current filehandle.  The

Since the client can't get a current FH (it is stale), I don't see how the client can
do a Close?

rick
ps: Basically what Trond said, but referencing the RFC.

----- Original Message -----

> waiting until the client chooses to close the file.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Fri, 24 Aug 2018 11:58:02 +0200 (CEST)

Makes sense: PUTFH+CLOSE will never work if file handle is invalid.

Thanks,
   Tigran.

----- Original Message -----
> From: "Rick Macklem" <[email-masked]>
> To: "Tigran Mkrtchyan" <[email-masked]>, "Trond Myklebust" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Friday, August 24, 2018 2:39:18 AM
> Subject: Re: Should client issue close in stale fh?