Subject: [nfsv4] [3530bis] Item #2

From: Thomas Haynes <[email-masked]>
Date: Mon, 14 Feb 2011 21:05:05 -0600

> 2) Explain what associated means in this context:
> 
> > In sec. 14.2.2 DESCRIPTION
> >
> >  The share reservations and other state information released
> >  at the server as a result of this CLOSE is only associated
> > with the supplied stateid.
> 
> Action:
> Owner:
> State: Accepted, Low
> Target:
> 

I think this is a non-issue, but I'd like to get agreement.

Looking at the full text:

> 15.4.4.  DESCRIPTION
> 
>    The CLOSE operation releases share reservations for the regular or
>    named attribute file as specified by the current filehandle.  The
>    share reservations and other state information released at the server
>    as a result of this CLOSE is only associated with the supplied
>    stateid.  The sequence id provides for the correct ordering.  State
>    associated with other OPENs is not affected.

The key is that the same client/lockowner might have multiple independent
OPENs on the same file, but indexed via different file handles. What this
text is stating, is that each OPEN needs a corresponding CLOSE and each
CLOSE only impacts the corresponding OPEN.

This is spelled out in section 9.11:

>    When the server chooses to export multiple filehandles corresponding
>    to the same file object and returns different filehandles on two
>    different OPENs of the same file object, the server MUST NOT "OR"
>    together the access and deny bits and coalesce the two open files.
>    Instead the server must maintain separate OPENs with separate
>    stateids and will require separate CLOSEs to free them.

I can change the text to make a stronger relationship than "associated", but
my problem is that it already reads fine to me. If it doesn't read fine to you
(or you believe I got the issue wrong), please respond.

---

From: Rick Macklem <[email-masked]>
Date: Tue, 15 Feb 2011 14:37:00 -0500 (EST)

> (or you believe I got the issue wrong), please respond.
Well, I don't know anywhere that "what are the associated locks"
exists in tthe RFC. After discussion. "associated" was established
by the open_to_lock_owner4 case of the Lock Op. (referring to byte
range locks, not open shares.)

rick

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 15 Feb 2011 14:41:11 -0800

> range locks, not open shares.)

Doesn't this describe it?

9.1.4.  Use of the stateid and Locking

   All READ, WRITE and SETATTR operations contain a stateid.  For the
   purposes of this section, SETATTR operations which change the size
   attribute of a file are treated as if they are writing the area
   between the old and new size (i.e., the range truncated or added to
   the file by means of the SETATTR), even where SETATTR is not
   explicitly mentioned in the text.

   If the lock_owner performs a READ or WRITE in a situation in which it
   has established a lock or share reservation on the server (any OPEN
   constitutes a share reservation) the stateid (previously returned by

Haynes & Noveck          Expires August 18, 2011              [Page 110]
^L
Internet-Draft                    NFSv4                    February 2011

   the server) must be used to indicate what locks, including both
   record locks and share reservations, are held by the lockowner.  If
   no state is established by the client, either record lock or share
   reservation, a stateid of all bits 0 is used.  Regardless whether a
   stateid of all bits 0, or a stateid returned by the server is used,
   if there is a conflicting share reservation or mandatory record lock
   held on the file, the server MUST refuse to service the READ or WRITE
   operation.

I.e., "associated" just means those locks held by that client on that file.

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 15 Feb 2011 15:04:34 -0800

> range locks, not open shares.)

Ahh, are you referring to this issue?

9) We should clarify the passage on NFS4ERR_LOCKS_HELD. Since lock owners
and open owners are different things, we need to clarify which locks may
trigger an NFS4ERR_LOCKS_HELD error on a CLOSE for a given open_stateid.
In the same vein, which locks does section 9.8 allow the server to free
when the client does a CLOSE? This all harks back to the mailing list
discussions about lock_stateids being
<per-file,per-open_owner,per-lock_owner> vs. just being
<per-file,per-lock_owner>

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 15 Feb 2011 18:52:03 -0500

> <per-file,per-lock_owner>

Correction:

        <per-_filehandle_, per-open_owner, per-lock_owner>

according to the paragraph in section 9.11 that you quoted to us
yesterday.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Rick Macklem <[email-masked]>
Date: Wed, 16 Feb 2011 16:34:52 -0500 (EST)

> <per-file,per-lock_owner>
Yep. Sorry about the noise.

Thanks for working on this, rick

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 16 Feb 2011 14:00:51 -0800

> Thanks for working on this, rick

What noise? You really helped me to understand what an
issue was about.

Thanks