Subject: [nfsv4] Draft-12 is coming

From: Spencer Shepler <[email-masked]>
Date: Mon, 09 Jul 2007 22:53:19 -0500

I submitted draft-12 today for publication.  You can find
an early copy at the usual location: www.nfsv4-editor.org

This draft includes updates to the pNFS sections based
on the review comments that were received along with
a few sessions tweaks.   The html-ized diff is available
on the site as well.

We seemed to have come to a consensus on the proposed
changes for the stateids in layouts and the handling
of deviceid mapping.  I will be working to make changes
to the specification to reflect Mike's proposals with
the intent of submitting draft-13 the week of the IETF
meeting.  I will be providing additional detail of the
changes on the WG alias and review them at the IETF
meeting to assist in any last minute changes.

Thanks,
Spencer

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

---

From: [email-masked]
Date: Thu, 12 Jul 2007 05:19:45 -0400

I have been reviewing the NFS-V41 draft 12 and I have an issue with
section 12.5.1.  The language in the last paragraph seems to preclude
using mandatory locks in conjunction with block layouts.  I say this
because I do not expect block devices to be able to implement
byte/octet/record range locking.

Perhaps we need a change the spec to say

   If the storage device
   is incapable of providing this check in the presence of mandatory
   file locks, the metadata server then MUST NOT grant intersecting
layouts and
                                   added "intersecting"----^
   mandatory file locks simultaneously to different clients.
                                      ^*******added********^

Comments?

Jason Glasgow
EMC

http://www.nfsv4-editor.org/drafts/drafts.html

12.5.1.  Guarantees Provided by Layouts

   Layouts delegate to the client the ability to access data located at
   a storage device with the appropriate storage protocol. ....
 
   ....

   In the presence of pNFS functionality, mandatory file locks MUST
   behave as they would without pNFS.  Therefore, if mandatory file
   locks and layouts are provided simultaneously, the storage device
   MUST be able to enforce the mandatory file locks.  For example, if
   ^**^
   one client obtains a mandatory lock and a second client accesses the
   storage device, the storage device MUST appropriately restrict I/O
   for the byte range of the mandatory file lock.  If the storage device
   is incapable of providing this check in the presence of mandatory
   file locks, the metadata server then MUST NOT grant layouts and
                                       ^********^
   mandatory file locks simultaneously.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 12 Jul 2007 16:24:41 +0300

Well the server can't mandate the byte range locks otherwise.
I don't see how you can support mandatory locking when you allow
direct client access to the device without being able to enforce
the locks there.  Without layouts the client has to funnel through
the server where and I/O can be intercepted and mandatory locks
can be enforced.  A client that previously tried I/O at the server
without holding a lock will now go directly to storage and the I/O
will go through although it must not when mandatory locks are in place
and there's a lock intersecting with the unlock I/O range.

Benny

---

From: [email-masked]
Date: Thu, 12 Jul 2007 10:55:43 -0400

For block layout drivers, the server can mandate locks as long as the
locks are on sector boundaries, and as long as the server only grants to
a client layouts that are compatible with the mandatory locks previously
acquired by that client.

It is a limitation, but not nearly as serious a limitation as preventing
the use of mandatory locks for block layout drivers.

-Jason

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 9:25 AM
To: Glasgow, Jason
Cc: [email-masked]
Subject: Re: [nfsv4] Using Mandatory file locks with block layouts

Benny

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Jul 2007 11:19:15 -0400

What this would require is that the client itself enforce
the mandatory locks with respect to other owners in the
same client.  That's doable but the spec has to make 
clear that that is its job, since there is no way for
the combination meta-data server and data server to do
it. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 5:20 AM
To: [email-masked]
Subject: [nfsv4] Using Mandatory file locks with block layouts

   If the storage device

Comments?

Jason Glasgow
EMC

 
   ....

---

From: Benny Halevy <[email-masked]>
Date: Thu, 12 Jul 2007 18:19:19 +0300

If I understand you correctly, you can dispatch layouts iff a client
has a byte range lock covering the layout byte range, right?
If so I think you're covered by the "simultaneously to different clients"
clause.

Benny

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Jul 2007 12:54:57 -0500

> the use of mandatory locks for block layout drivers.

As Benny pointed out, the language you quoted would allow what
you described above.  The locks would be on sector boundaries
and the server would ensure to provide layouts accordingly.
That is allowed.

Spencer

---

From: [email-masked]
Date: Thu, 12 Jul 2007 14:04:59 -0400

I am glad to hear that there is consensus that spec allows such
behavior.  

I read the specification differently, and thought that the unqualified
references to "layouts" precluded this.  I stand corrected.

-Jason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 1:55 PM
To: Glasgow, Jason
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Using Mandatory file locks with block layouts

Spencer

---

From: "Muntz, Daniel" <[email-masked]>
Date: Thu, 12 Jul 2007 11:58:26 -0700

Does this imply that a buggy/malicious client would be capable of
violating mandatory locks?

  -Dan

-----Original Message-----
From: Noveck, Dave 
Sent: Thursday, July 12, 2007 8:19 AM
To: [email-masked]; [email-masked]
Subject: RE: [nfsv4] Using Mandatory file locks with block layouts

What this would require is that the client itself enforce the mandatory
locks with respect to other owners in the same client.  That's doable
but the spec has to make clear that that is its job, since there is no
way for the combination meta-data server and data server to do it. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2007 5:20 AM
To: [email-masked]
Subject: [nfsv4] Using Mandatory file locks with block layouts

   If the storage device

Comments?

Jason Glasgow
EMC

 
   ....

---

From: Marc Eshel <[email-masked]>
Date: Thu, 12 Jul 2007 12:58:56 -0700

> of deviceid mapping.  I will be working to make changes

We had a short discussion of this proposal in our weekly pNFS/Linux status 
meeting and it was not clear to us that a consensus was reached. Will it 
be possible for Mike to post the last version of the proposal again before 
it goes to draft-13?

Thanks, Marc.

---

From: Garth Goodson <[email-masked]>
Date: Thu, 12 Jul 2007 13:05:06 -0700

> violating mandatory locks?

Yes. But given that a buggy/malicious block based pNFS client can write 
anywhere on the block device to which it has access, this seems like the 
least of your worries...

-Garth

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Jul 2007 19:26:34 -0500

> be possible for Mike to post the last version of the proposal again  

Well, yes and no.  If there are issues with what has been
proposed, they should be mentioned on the WG alias.  If there
is a need for additional detail in a particular area, please
ask for clarifications.

The editorial work to integrate the proposal into the specification
will be large enough that I would prefer any issues be raised now.

I can work to extend Mike's proposal slightly given the thread
of discussion on the WG but again, I would prefer comments now.

Spencer

---

From: Marc Eshel <[email-masked]>
Date: Thu, 12 Jul 2007 17:44:19 -0700

> of discussion on the WG but again, I would prefer comments now.

I am not sure what is the final state of the proposal for which you assume 
that there is consensus. There where comments and suggestion which might 
have changed to initial proposal. One specific question I had is are we 
going to keep the recall all layouts for a given fsid. Few of us were not 
clear on the final proposal so I think we need another review before it 
goes into the draft.
Marc.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Jul 2007 19:49:19 -0500

On Jul 12, 2007, at 7:44 PM, Marc Eshel wrote:
>  Few of us were not

I will put together a summary of what will be changed.

Spencer