Subject: [nfsv4] layout and retrun-on-close

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Wed, 27 May 2015 10:07:34 +0200 (CEST)

Hi All,

I think this is a similar race condition as was described by Olga for delegation.

Let say we have a client and a server. The client holds a layout with a roc flag
for a file. Now client sends OPEN and CLOSE in parallel. Those two requests can
be processed by server in different order:

server : 

Thread 1: CLOSE, invalidate layout (as there are no other opens on that file)
Thread 2: OPEN

At this point client may assume that layout still valid, but this is not true
any more.

Did I miss something?

Tigran.

---

From: Benny Halevy <[email-masked]>
Date: Wed, 27 May 2015 12:34:52 +0300

> At this point client may assume that layout still valid, but this is not true

How can the client assume that without serializing the OPEN before CLOSE?
Since the OPEN operation does not provide the open/deleg stateid in the
request, the client must serialize its respective OPENs and CLOSEs for the
provided open owner and respective stateid if it cares about the outcome.
Alternatively, it may look at the stateid.other component in the response
and compare it for quality with the one it held to figure out if the OPEN
won the race against CLOSE or not.

Benny

> 
> Did I miss something?
> 
> Tigran.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Wed, 27 May 2015 11:47:54 +0200 (CEST)

probably I did not express me correct.

Here is the scenario:

Client                 Server
------                 -------

(ct1) OPEN
(ct1) LAYOUTGET
(ct2) OPEN
(ct1) CLOSE

                        (st1) CLOSE
                        (st1) DISCARD LAYOUT
                        (st2) OPEN

where ctX and stX represent client and server threads.
Two OPENS may come from different processes.
We have such situations when similar jobs end-up on the
same processing node.

Tigran.

----- Original Message -----
> From: "Benny Halevy" <[email-masked]>
> To: "Mkrtchyan, Tigran" <[email-masked]>, "NFSv4" <[email-masked]>
> Cc: "Olga Kornievskaia" <[email-masked]>
> Sent: Wednesday, May 27, 2015 11:34:52 AM
> Subject: Re: [nfsv4] layout and retrun-on-close

---

From: Benny Halevy <[email-masked]>
Date: Wed, 27 May 2015 14:20:08 +0300

> probably I did not express me correct.

Then the client better serialize opens, closes / open_downgrade / deleg_return
(and other open stateid mutating operations like delegation reclaim)
that correspond to same open owner. Otherwise, it can go out of sync
also with regards to the share / deny mode

Benny

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 27 May 2015 08:26:10 -0400

> At this point client may assume that layout still valid, but this is not true

The client can choose to be conservative in that case, and assume that
the CLOSE was processed before the OPEN. Forgetful client semantics
means that this is allowed by the protocol.

Cheers
  Trond