Subject: [nfsv4] re...more on open with claim_delegate_prev

From: [email-masked]
Date: Sun, 14 Dec 2003 15:40:18 -0500 (EST)

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

Nope, if the client doesn't want the delegation any longer, it doesn't do
the open with Claim_delegate_prev and gets rid of them with a Delegpurge,
after doing open with Claim_delegate_prev for the ones it does care about.

> 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.
If the client doesn't care about the delegation, it can just do an open
with Claim_null and let the server decide whether to reinstate the
delegation or just throw it away, if it still happens to exist on the server.

[Last para on pg. 96, sec. 9.2.1]
	...it MUST NOT remove delegations upon SETCLIENTID_CONFIRM, and
	instead MUST, for a period of time no less than that of the value
	of the lease_time attribute, maintain the client's delegations to
	allow time for the client to issue CLAIM_DELEGATE_PREV...

--> From that, I infer that the client is expected to do the opens with
	CLAIM_DELEGATE_PREV within "lease time interval" of the
	Setclientid_confirm.

I can't think of anything in the RFC that says it can't do an Open with
claim_null during that same time period, if it doesn't care whether or
not the delegation is reinstated. Is there such a restriction?

I see the purpose of an open with claim_delegate_prev being a way for
the client to ensure it will be notified via a CBRecall of any conflicting
open and, as such, will be allowed to write dirty data back to the server,
invalidate cached data, etc, at that time.

> 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.

I'm not sure what you mean by "assumptions on behalf of the client". I
think all I am assuming is that a client might care if the old delegation
was lost. If it didn't care about old delegations, why would it bother
to keep them on stable storage in the first place?

> 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'm not familiar with the semantics of cache_fs, but I was assuming the
client might keep entire files (or even file subtrees) on local stable
storage and need not bother to ever write the dirty data back until
"someday", when the server issues a CBRecall. (Near disconnected, if you like.
It has to keep the lease renewed, so it can't be truly disconnected.)

> 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.

Except for these cases, why would a client bother to keep delegations on
stable storage? (I don't think any current client does this, they just
reboot, setclientid, and then do opens with claim_null when they want files
open. Does any current client out there use Claim_delegate_prev?)

> However in that case, it is up to the _client_ to decide how to resolve
> the ambiguities.

Yes, but it seems to me the client will want to know if the "rights granted"
by the old delegation are still intact on the server, so it knows if
there are ambiguities that need to be resolved.
[stuff snipped]
>   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.
My understanding is that, so long as the client does the Open with
claim_delegate_prev within one lease time of the SetClientID_confirm, it
is guaranteed to succeed, assuming the server supports claim_delegate_prev
in the first place.

It appears we have a somewhat different idea of what the purpose of
an Open with claim_delegate_prev is.

Anyone else have comments? rick

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