Subject: [nfsv4] pNFS: What stateid should be used in LAYOUTGET

From: "Mora, Jorge" <[email-masked]>
Date: Tue, 20 Sep 2011 12:51:49 -0700

Hello,

According to the RFC Section 18.43.3:

   The loga_stateid field specifies a valid stateid.  If a layout is not
   currently held by the client, the loga_stateid field represents a
   stateid reflecting the correspondingly valid open, byte-range lock,
   or delegation stateid.  

But there is no clear priority of stateid to use for LAYOUTGET.
When doing I/O the stateid to use should be the delegation stateid if a delegation exists,
the lock stateid if no delegation exists, or the open stateid if no delegation and no
lock exist (Section 8.2.5).

Does the LAYOUTGET should follow the same rules for the stateid to use as in section 8.2.5?
More specifically, for the following example:

OPEN file
LOCK file
LAYOUTGET

Should the LAYOUTGET use the open or the lock stateid?

--Jorge

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 21 Sep 2011 11:49:16 -0400

> Should the LAYOUTGET use the open or the lock stateid?

The spec appears to be broken here.

On the one hand, the mds SHOULD return NFS4ERR_LOCKED if a layout
conflicts with a mandatory lock and the storage devices has no way of
enforcing them other than by restricting layouts.

On the other hand, the client is only allowed to present an open/lock or
delegation stateid on the very _first_ LAYOUTGET call: the rest of the
time it MUST use the layout stateid.

So how is the server supposed to enforce locks if it doesn't know who is
requesting the layout? AFAICS, at best it can enforce the requirement
that some process on the client holds a valid mandatory lock for that
region, however it cannot know whether or not that process is the one
that is going to write, (or even whether that process is the one that is
attempting the LAYOUTGET).

IOW: my question would be whether there is any point in ever using a
lock stateid with the LAYOUTGET?

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com