Subject: Re: [nfsv4] IETF 78 NFSv4 session currently schedule for Wednesday afternoon - 1-3:30pm

From: Trond Myklebust <[email-masked]>
Date: Sat, 03 Jul 2010 18:01:21 -0400

On Thu, 2010-06-24 at 18:10 -0500, Spencer wrote:
> Full draft agenda may be found here:
> https://datatracker.ietf.org/meeting/78/agenda.html
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

Hi Spencer,

I'd like a 10-15 minute slot to talk about some NFSv4 migration issues.

Cheers,
  Trond

---

From: Jwu-Shyan Tarng <[email-masked]>
Date: Sat, 3 Jul 2010 19:51:47 -0700

Can someone help to answer the following questions?
- Can the previous V4 OPEN with CLAIM=CLAIM_DELEGATE_CUR impact on
  the later V4 OPEN delegation grant with different SHARE access
  since CLAIM_DELEGATE_CUR is done as part of recalling a delegation based 
on RFC?
- There is a test sequence in the following:
1 OPEN for Read which gets READ delegation with delegation stateid, 
dstateid, andopen stateid, ostateid
2 Read with dstateid. 
  - Expect NFS4_OK 
3 CLOSE with ostateid
  - Expect NFS4_OK 
4 OPEN with CLAIM=CLAIM_DELEGATE_CUR with dstateid and get open stateid, 
ostateid2, back.
  Read with dstateid. 
  - Expect NFS4_OK 
  Read with ostateid2. 
  - Expect NFS4_OK 
5 OPEN for write for this file (like OPEN upgrade)
  Questions: 
  1) Is the old dstateid still valid now?
     If it is still valid, is this dstateid representing READ delegation 
or WRITE delegation?
  2) Can this open for write get write delegation stateid besides open 
stateid returned to 
     the client? 
     If there is no delegation stateid returned to the client, is there 
any delegation existing 
     on the client side?

Regards,

Jwu-Shyan Tarng
NFS Development

---

From: "Sorin Faibish" <[email-masked]>
Date: Sun, 04 Jul 2010 09:22:29 -0400

Now that Trond opened this I would like to have 20 min to talk about the  
permission access draft
that we intent to finalyze after this meeting. We (me and David Black)  
want to have 30min
discussion on the Storage Preferences for virtualization (continuation of  
the last
discussion from Anaheim) but in the room not outside like in Anaheim.  
David Black will
present few slides to open the discussion.

Thanks Spencer and congrats on your new position.

/Sorin

-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Rick Macklem <[email-masked]>
Date: Sun, 4 Jul 2010 11:56:41 -0400 (EDT)

>     If it is still valid, is this dstateid representing READ delegation

I don't believe that it can become a WRITE delegation, but I do believe
that it is still valid until DelegReturn'd. (See below.)
>     If there is no delegation stateid returned to the client, is there
Hmm, interesting question. I'm interested in hearing what others say, but
here's my take on it:
- I would only expect a client to use OPEN_DELEGATE_CUR to get an Open
   when the client decides to Delegreturn the delegation, in order to get
   an Open against the server to replace locally issued Opens on the
   delegation.
   Since the delegation allows Opens to be done locally in the client,
   why would the client do an Open with OPEN_DELEGATE_CUR except when
   it needs to return the delegation? (Because of a server issued CBRECALL
   or maybe a resource constraint issue in the client such that it decides
   it needs to return the delegation.)
- As such, since the delegation is being returned, I believe a client
   is expected to Delegreturn it asap but that it continues to work as a
   read delegation until it is DelegReturn'd. My client does not use the
   delegation for anything else once it starts the process of returning
   the delegation, which is when the OPEN_DELEGATE_CUR Opens are done.
   (I don't believe that this is required behaviour, but I found that I
    had to shut down all other Open/Lock state related activities on the
    clientid while returning the delegation in order to get it to work
    correctly in my client.)

rick

---

From: Trond Myklebust <[email-masked]>
Date: Sun, 04 Jul 2010 12:21:17 -0400

On Sat, 2010-07-03 at 19:51 -0700, Jwu-Shyan Tarng wrote:
> - Can the previous V4 OPEN with CLAIM=CLAIM_DELEGATE_CURimpact on
>  since CLAIM_DELEGATE_CURis done as part of recalling a delegation
> based on RFC? 
> 
> 1 OPEN for Readwhich gets READ delegation with delegation stateid,
> dstateid,andopen stateid, ostateid
> 2 Read with dstateid. 
>  - Expect NFS4_OK 
> 3 CLOSE with ostateid
>  - Expect NFS4_OK 
> 4 OPEN with CLAIM=CLAIM_DELEGATE_CURwith dstateid and get open
> stateid, ostateid2, back.
>  Read with dstateid. 
>  - Expect NFS4_OK 
>  Read with ostateid2. 
>  - Expect NFS4_OK 
> 5 OPEN for writefor this file (like OPEN upgrade)
>  Questions: 
>     If it is still valid, is this dstateid representing READ
> delegation or WRITE delegation?

According to section 9.4.4 of RFC3530, the OPEN for write won't succeed
until the read delegation has been returned, so the answer is

  1) no
  2) yes

Cheers
  Trond

---

From: Tom Haynes <[email-masked]>
Date: Sun, 4 Jul 2010 15:29:44 -0500

That is close to 1/2 of the meeting.

We either need more time or need to frontload the discussion online.

We had talked about both options at IETF 78...

On Jul 4, 2010, at 8:22 AM, Sorin Faibish <[email-masked]> wrote:

> Now that Trond opened this I would like to have 20 min to talk about the permission access draft
> that we intent to finalyze after this meeting. We (me and David Black) want to have 30min
> discussion on the Storage Preferences for virtualization (continuation of the last
> discussion from Anaheim) but in the room not outside like in Anaheim. David Black will
> On Sat, 03 Jul 2010 18:01:21 -0400, Trond Myklebust <[email-masked]> wrote:
>

---

From: "Sorin Faibish" <[email-masked]>
Date: Sun, 04 Jul 2010 16:41:40 -0400

> That is close to 1/2 of the meeting.
Not sure I follow: 15+20+30=65 out of 150. Are there other agenda topics  
that will take
more than 85 minutes? If so we can make room for all the topics.

> We had talked about both options at IETF 78...
I just presented the permission draft, now after the discussion in the  
email we came to a final
proposal before last call which we want to discuss. As about the storage  
preferences we have
to discuss the concrete options we are proposing to discussion before the  
draft. As you can
remember we had a lot of corridor discussions that we need to have in the  
WG. We can reduce the
time if there are conflicts and time shortage.

/Sorin

        EMC²
where information lives

---

From: <[email-masked]>
Date: Tue, 6 Jul 2010 11:48:02 -0400

There is no provisions for delegation upgrade.  I don't think it says
that anywhere but I would assume that the fact that this is not
described allows you to assume that it does not exist.
 
So, in your example, when you do the open for write, the delegation will
be recalled.  If you know that is going to happen, the client is
well-advised to return the read delegation in the COMPOUND, before doing
the open upgrade. 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jwu-Shyan Tarng
Sent: Saturday, July 03, 2010 10:52 PM
To: nfsv4 nfsv4
Subject: [nfsv4] NFS V4 OPEN delegation with CLAIM_DELEGATE_CUR

- Can the previous V4 OPEN with CLAIM=CLAIM_DELEGATE_CUR impact on
 the later V4 OPEN delegation grant with different SHARE access
 since CLAIM_DELEGATE_CUR is done as part of recalling a delegation
based on RFC? 

Regards,

Jwu-Shyan Tarng
NFS Development

---

From: Dean Hildebrand <[email-masked]>
Date: Tue, 06 Jul 2010 09:40:23 -0700

On 7/4/2010 1:41 PM, Sorin Faibish wrote:
> Not sure I follow: 15+20+30=65 out of 150. Are there other agenda 
> topics that will take

I'll be in Maastricht, and I'm hoping that a good portion of the meeting 
will be deciding on the final items to be included in NFSv4.2.  My 
understanding is that most of the known items have been proposed and 
presented at previous meetings, and so this should be a good opportunity 
to present any remaining items and propose a final list.

Dean

> proposal before last call which we want to discuss. As about the 
> storage preferences we have
> to discuss the concrete options we are proposing to discussion before 
> the draft. As you can
> remember we had a lot of corridor discussions that we need to have in 
> the WG. We can reduce the

---

From: <[email-masked]>
Date: Tue, 6 Jul 2010 13:01:28 -0400

Making progress on v4.2 sounds sensible but I don't see allocating a large portion of 85 minutes to what might turn out to be an unstructured discussion of possible additions to NFSv4.2 (assuming that we are now OK as far as this being on the working group's charter).  We could certainly use up the time but I don't see that more than 20 minutes would be useful in trying to come up with a proposed "final" list for group discussion.

If people have proposed additions, I should think that they would be able to put together a few slides and propose it as part of the meeting, before this 20-minute session.  I think that that session should be filtering things already proposed and not accumulating last-minute proposals.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Hildebrand
Sent: Tuesday, July 06, 2010 12:40 PM
To: [email-masked]
Subject: Re: [nfsv4] IETF 78 NFSv4 session currently schedule for Wednesday afternoon - 1-3:30pm

Dean

---

From: Tom Haynes <[email-masked]>
Date: Tue, 06 Jul 2010 12:17:59 -0500

> more than 85 minutes? If so we can make room for all the topics.

I'm anticipating more presentations - so close to half on 3 means that 
we have time for
3 more.

> time if there are conflicts and time shortage.

One of the things I remember was that not everyone had read the drafts
before the event. We talked about assigning readers?

I.e., I'm also suggesting we make sure to read the drafts before we start
talking about them.

---

From: Tom Haynes <[email-masked]>
Date: Tue, 06 Jul 2010 12:44:28 -0500

On 07/ 6/10 12:01 PM, [email-masked] wrote:
> Making progress on v4.2 sounds sensible but I don't see allocating a large portion of 85 minutes to what might turn out to be an unstructured discussion of possible additions to NFSv4.2 (assuming that we are now OK as far as this being on the working group's charter).

Which we should clarify.

I think Spencer did that in
http://www.ietf.org/mail-archive/web/nfsv4/current/msg07833.html

>   We could certainly use up the time but I don't see that more than 20 minutes would be useful in trying to come up with a proposed "final" list for group discussion.
>

I thought we had a current proposal:

http://tools.ietf.org/id/draft-eisler-nfsv4-minorversion-2-requirements-02.txt

And I seem to recall Mike asking us to approve that in Anaheim.

---

From: Dean Hildebrand <[email-masked]>
Date: Tue, 06 Jul 2010 13:40:58 -0700

> If people have proposed additions, I should think that they would be able to put together a few slides and propose it as part of the meeting, before this 20-minute session.  I think that that sessi…

On this note, I actually would like to request 5-10 minutes to discuss 
another modest proposal (in addition to our existing proposal to handle 
sparse file located here 
http://tools.ietf.org/html/draft-hildebrand-nfsv4-read-sparse-00)

I would like to propose a method for NFS to perform direct I/O on the 
server to the exported file system.
Direct I/O (O_DIRECT) is a common way for applications that either 
manage caching themselves, perform
large I/O, or realize poor cache hit rates to avoid the overhead of 
using the page cache.  Example applications
include HPC, DB, and virtual machines.  In NFS, when applications open a 
file with the O_DIRECT flag, the
NFS client bypasses the page cache and delivers data directly to/from 
the application.  But in this scenario,
the server file system is unaware of the client's behaviour and 
continues to cache data blocks, possibly
reducing I/O performance and/or polluting the server cache.

We propose to modify either the OPEN RPC (or both the READ and WRITE 
RPCs) to pass the
O_DIRECT flag from the NFS client to the NFS server as a hint.  The NFS 
server can then
pass this flag to the underlying file system when it opens the file.  
This gives the underlying server
file system the option to either perform or not perform direct I/O on 
all I/O to this file.

Dean Hildebrand
IBM Almaden

>> On Sun, 04 Jul 2010 16:29:44 -0400, Tom Haynes<[email-masked]>
>> wrote:
>>
>>      
>>> On Jul 4, 2010, at 8:22 AM, Sorin Faibish<[email-masked]>  wrote:
>>>
>>>

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 6 Jul 2010 17:58:31 -0400

While we're suggesting, I already asked Spencer for a slot on the FedFS proposals, including the SRV-based name space one that recently went through last call.  I'd hope for at least 15 minutes.

                                Craig

From: Dean Hildebrand [mailto:[email-masked]] 
Sent: Tuesday, July 06, 2010 4:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] IETF 78 NFSv4 session currently schedule for Wednesday afternoon - 1-3:30pm

 

On this note, I actually would like to request 5-10 minutes to discuss another modest proposal (in addition to our existing proposal to handle sparse file located here http://tools.ietf.org/html/draft-hildebrand-nfsv4-read-sparse-00 <http://tools.ietf.org/html/draft-hildebrand-nfsv4-read-sparse-00> )

I would like to propose a method for NFS to perform direct I/O on the server to the exported file system.
Direct I/O (O_DIRECT) is a common way for applications that either manage caching themselves, perform
large I/O, or realize poor cache hit rates to avoid the overhead of using the page cache.  Example applications
include HPC, DB, and virtual machines.  In NFS, when applications open a file with the O_DIRECT flag, the
NFS client bypasses the page cache and delivers data directly to/from the application.  But in this scenario,
the server file system is unaware of the client's behaviour and continues to cache data blocks, possibly
reducing I/O performance and/or polluting the server cache.

We propose to modify either the OPEN RPC (or both the READ and WRITE RPCs) to pass the
O_DIRECT flag from the NFS client to the NFS server as a hint.  The NFS server can then
pass this flag to the underlying file system when it opens the file.  This gives the underlying server
file system the option to either perform or not perform direct I/O on all I/O to this file.

Dean Hildebrand
IBM Almaden

 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Hildebrand
Sent: Tuesday, July 06, 2010 12:40 PM
To: [email-masked]
Subject: Re: [nfsv4] IETF 78 NFSv4 session currently schedule for Wednesday afternoon - 1-3:30pm

	On Sun, 04 Jul 2010 16:29:44 -0400, Tom Haynes <[email-masked]> <mailto:[email-masked]>  
	wrote:

 
 
Dean

		 

	 
	/Sorin

		On Jul 4, 2010, at 8:22 AM, Sorin Faibish <[email-masked]> <mailto:[email-masked]>  wrote:

			Now that Trond opened this I would like to have 20 min to talk about 
			the permission access draft
			that we intent to finalyze after this meeting. We (me and David 
			Black) want to have 30min
			discussion on the Storage Preferences for virtualization 
			(continuation of the last
			discussion from Anaheim) but in the room not outside like in 
			Anaheim. David Black will
			present few slides to open the discussion.

			/Sorin
			 
			On Sat, 03 Jul 2010 18:01:21 -0400, Trond Myklebust 
			<[email-masked]> <mailto:[email-masked]>  wrote:

					 

				Hi Spencer,
				 
				I'd like a 10-15 minute slot to talk about some NFSv4 migration 
				issues.
				 
				Cheers,
				 Trond

				          

			 
			 
			      EMC²
			where information lives

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 07 Jul 2010 10:22:55 -0400

> And I seem to recall Mike asking us to approve that in Anaheim.

I'm not going to be at Masstricht or Bejing but I'd like to mention that
I'm still committed to the Labeled NFS work which is in the 4.2
requirements document under the compliance section.

Dav

---

From: Tom Haynes <[email-masked]>
Date: Thu, 08 Jul 2010 18:00:34 -0500

I'm also going to need 10 minutes to discuss RFC3530bis.

---

From: sfaibish <[email-masked]>
Date: Thu, 08 Jul 2010 19:52:45 -0400

I think that Dave Noveck will have a spot for this.

-- 
Best Regards

Sorin Faibish
Network Storage Group

         EMC²
where information lives

---

From: Tom Haynes <[email-masked]>
Date: Fri, 09 Jul 2010 01:20:13 -0500

> I think that Dave Noveck will have a spot for this.

Dave is going to talk about i18n.

I'll talk about the rest of the changes going into 3530bis.