Subject: [nfsv4] re: re: open with delegate_prev

From: [email-masked]
Date: Sat, 13 Dec 2003 21:15:05 -0500 (EST)

Trond writes:
> What extra information does that convey to the client? It already
> knows why the delegation is not being granted.
> 
Only if everyone agreed that the only reason a server would issue
an open but not a delegation in this case is that the old delegation expired
on the server (not "I'm low on resources, so won't re-issue it or...").
(ps: I'm not suggesting that this should happen, I believe that returning
 an error if the old delegation has been lost is the correct response.)

> All you'd be doing is to force it to issue yet another open call over
> the wire...
Yes, if the client wanted an open. (See below.)

> Yes. The *purpose* of calling OPEN is to open the file. What would be
> the point of requesting a delegation if you are not intending to use
> it?
In this case, I don't see it as "the client requesting a delegation". I
see it as "the client is reinstating the delegation it already has".

> 
> Delegations are an *optimization*. They are a means to an end, and not
> an end in themselves...
I see it as more than an *optimization* (in the sense I think you mean?).
It can potentially allow a client to manipulate Gbytes of data for weeks
or even months, while only doing Renews within the server's lease time.
(Doing this using client side stable storage is, to me, the really neat
 part of V4. Someday I hope to get around to playing with it.)

> As I understand it, the main use of CLAIM_DELEGATE_PREV should be if a
> client has a copy of the file in its local cachefs and wants to
> revalidate that copy after it has rebooted. When OPENing the file, it
> needs to ask the server whether it can still trust the contents of its
> cachefs.
Well, I agree (except the capitalization of OPEN:-). I would have
described it as "opening a file to reinstate the DELEGATION".

If the answer is
"old delegation expired", the client is in a very difficult situation, if it
was a write delegation and the client still has dirty data. Does it do another
Open and write the data back to the server, potentially overwriting
changes done by another client?
OR
does it try and let the user know
that it has lost consistency with the server, so the user can go and
merge changes manually?
OR???
Not obvious to me what the client should do,
but it doesn't necessarily want another open. It does, however, need to
know the old delegation state expired, so it is aware that another client
might have modified the file.

Saadia writes:
> IMHO, it does not make sense for the open to succeed if the server can
> not give out a delegation with it. The server should return an error in
> this case, maybe NFS4ERR_EXPIRED.
Sorry Trond, but I'm definitely in Saadia's camp on this one, rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 13 Dec 2003 23:40:32 -0500

> on the server (not "I'm low on resources, so won't re-issue it

You might agree to return NFS4ERR_RESOURCE if the latter is indeed the
case. I still think that is a bad reason to deny the OPEN due to point
(b) listed below.

> described it as "opening a file to reinstate the DELEGATION".

Ugh... You're of the opinion that the client should be reinstating
delegations on reboot without a reason? What is the interest of that?

It costs at least one RPC call per file to reinstate a delegation, and
the cost is the same for the server to recall it. What is the point of
issuing an OPEN call if you are not sure that you'll be using the file? 

If you decide to defer the OPEN call until you actually need the file,
then the cost is at worst the same. In the case where the file is opened
by another client using a conflicting mode, the performance of the lazy
open is actually _better_ since the server will not need to perform an
expensive recall of the delegation.

> might have modified the file.

I don't see why that is relevant here at all. Why are you having your
server make these assumptions on behalf of the client? The issue here is
simple: the client is requesting an OPEN of the file! The server can
either grant it now, or can force the client to jump through hoops in
order to retry the operation.

To answer the implied question though.
In most cases, the client will not have dirty data (assuming that it
shut down correctly) but will simply want to revalidate its existing
cache. As I argued above, the lazy open case make by far the best sense
here.

I agree that there are _corner_cases_ where the client crashed before it
could write back dirty data, or the client allows for some form of
disconnected operation and thus has cached dirty data. In those cases
you might have the sort of dilemma that you are discussing above where
the lazy open is not a good idea for cache consistency arguments.
However in that case, it is up to the _client_ to decide how to resolve
the ambiguities.
Even for that case, I would urge server implementations to *grant* the
OPEN call without a delegation, since

  a) A careful client can easily call CLOSE without causing any
prejudice whatsoever to the existing file and the server state.

and most importantly

  b) The retried OPEN call is _not_guaranteed_to_succeed_ no matter how
careful the client is. Other clients may inject RPC calls containing an
OPEN with conflicting deny bits, a REMOVE, a RENAME, or even a SETATTR
with acl changes.

IOW: I think there is a good case for arguing that returning an error
will lead to unnecessary bugs without conveying any useful information
to the client.

Cheers,
  Trond