Subject: RE: [nfsv4] Byte range delegations draft....

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 14 Jul 2005 08:55:44 -0400

> Another case for the SESSIONS crowd to solve. 8-)

Sessions crowd has solved it.  You don't need the open sequence
for replay if you are using sessions and they will be available
(though optional) in 4.1.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Thursday, July 14, 2005 7:50 AM
To: Benny Halevy
Cc: [email-masked]
Subject: Re: [nfsv4] Byte range delegations draft....

to den 14.07.2005 Klokka 08:44 (+0300) skreiv Benny Halevy:

> > You cannot send the DELEG_OPEN together with the OPEN as it takes an
> > open_stateid and open_seqid argument. It must therefore be called after
> > OPEN, but before the first call to DELEG_RANGE or READ.
> 
> This reminds me of the discussion to add to the protocol a 
> "current stateid", similar to the current fh, that could 
> carry the stateid returned by one operation to further 
> operations in the compound RPC...

I've been one of the main supporters of that concept, so I'm well aware
of it. ;-)

I'm not sure that you want to do that here, though, since you would end
up bumping the same open sequence id twice in the same COMPOUND (once
for the OPEN call and once for the DELEG_OPEN). That again means that
the COMPOUND can never be replayed in case, say, where a network
partition causes the initial reply from the server to be lost.

Another case for the SESSIONS crowd to solve. 8-)

> I think that the only reasonable way to do it is defining a 
> new special value for the stateid that will be interpreted 
> as the "current stateid".

The proposal includes a concept of a current delegation stateid, which
is used in order to allow the client to pass both the ordinary open
stateid and the delegation stateid to operations like READ, WRITE and
friends.
Not exactly what you are proposing here, though.

Cheers,
  Trond

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Jul 2005 09:14:55 -0400

to den 14.07.2005 Klokka 08:55 (-0400) skreiv Noveck, Dave:
> Sessions crowd has solved it.

Poor wording on my part. I meant that this is an application for
sessions.

>   You don't need the open sequence

Right, but I didn't want to tie byte range delegations to sessions (at
least not until we can make them mandatory to implement).

Returning to the original point, though. Note that a file delegation
makes the byte range delegation pretty much redundant, so if the OPEN
returns the former then you probably just want to drop calling
DELEG_OPEN to save the server from having to track that extra state.

Cheers,
  Trond

---

From: eric kustarz <[email-masked]>
Date: Thu, 14 Jul 2005 10:31:49 -0700

>DELEG_OPEN to save the server from having to track that extra state.
So the byte range delegation is superior in that if you only need to 
read part of the file, then a writer doesn't necessarily recall the byte 
range read delegation(s).  So for very large files, this would be good.

Anyone know why the original file delegation model was for whole files 
and not byte ranges?

eric

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Jul 2005 14:01:04 -0400

> range read delegation(s).  So for very large files, this would be good.

Yes. It also allows you to downgrade the write delegation to a read
delegation when you are done writing. That too should help to prevent
server recalls in a number of scenarios.

Cheers,
  Trond