Subject: [nfsv4] Write Open and Read Delegation

From: [email-masked]
Date: Fri, 8 Aug 2003 11:51:45 -0400 (EDT)

Hi,

> I don't think that's correct.  You can't have a file
> open for write when you have a read delegation.  Read
> delegations only allow you to have files open for read.
> 
> It seems that what you are doing here is silently 
> turning a read delegation into a write delegation and
> that would only work if clients were prepared for that.

Note that I wasn't referring to a "silent upgrade", I just assumed that
a client was allowed to have a Read Delegation for file X (which allows
it to do further Opens for Read without contacting the server) and a
Write Open for file X (with no delegation, so it must do Open ops on
the server for any additional Write opens, locks, close of the Write opens,
etc.).

If a client can't hold a Write Open without delegation and a Read Open
with Delegation on a file at the same time, does this also mean:

Client Opens X for Writing	Server allows Open, doesn't issue a Delegation
Client Opens X for Reading
				Now, the server can't issue a Read Delegation
				since a Write Open exists for X for the same
				client? Can it issue a Write Delegation as
				a part of the Read Open, assuming no conflicts?

This can easily happen, since the server can't issue a Delegation for any
Open with a new open_owner.

Note that, at the end of para. 6 in Sec. 9.2, it states:
	"Following the resolution of the recall, the server has the
	 information necessary to grant or deny the second client's request."

and in the first para. of 9.4
	"In particular, the server may receive a conflicting OPEN from
	 another client,..."

To me "second client or another client" here implies that a conflict occurs when
a different client does a conflicting open. (I guess it comes down to the
definition of "conflict"?)

If a client cannot hold a Read Delegation while it has a Write Open on the
same file, it seems to me the client should be required to Return the Read
delegation before it does the Write Open request?

I admit I don't like the idea of doing a Recall to the same client making
the Open request for the same file, given the problem scenario listed in the
previous emails. (I also suspect that a deadlock situation is pretty easy to get
into in both the client and server implementation, due to node locks or similar.)

Oh well, I can easily add a Recall to my server, if that's what is expected,
rick

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

---

From: "Khan, Saadia" <[email-masked]>
Date: Fri, 8 Aug 2003 11:39:17 -0700

> If a client can't hold a Write Open without delegation and a 
> Read Open with Delegation on a file at the same time, does 
> this also mean:
> 

It cant issue a write delegation if _another_ client has the file open
for write. I guess the server can check if the same client already has
the file open for write, and then it can issue a write delegation to it.

> This can easily happen, since the server can't issue a 
> Delegation for any Open with a new open_owner.
> 

What do you mean? Delegations are per client and not per open_owners?

> To me "second client or another client" here implies that a 
> conflict occurs when a different client does a conflicting 
> open. (I guess it comes down to the definition of "conflict"?)
> 
> If a client cannot hold a Read Delegation while it has a 
> Write Open on the same file, it seems to me the client should 
> be required to Return the Read delegation before it does the 
> Write Open request?

Right now that is what the solaris client does. It voluntarily returns
the read delegation before doing a write to the same file.

Saadia

> 
> I admit I don't like the idea of doing a Recall to the same 
> client making the Open request for the same file, given the 
> problem scenario listed in the previous emails. (I also 
> suspect that a deadlock situation is pretty easy to get into 
> in both the client and server implementation, due to node 
> locks or similar.)
> 
> Oh well, I can easily add a Recall to my server, if that's 
> what is expected, rick
>

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 11 Aug 2003 15:03:32 -0700

> the server for any additional Write opens, locks, close of the Write
opens,

OK.  I hadn't assumed that that was possible.  That's not to say it
is a bad idea or even that the spec forbids it, but it certainly wasn't
thought about as possible when this stuff was designed.

> 				client? 

Correct.

>                       Can it issue a Write Delegation as

My current interpretation is the existing Write Open is a conflict.
However you are making a good case that that interpretation is less
than ideal.  I really need to think about this some more.  

> Open with a new open_owner.

If the server knows it is a new open_owner then there is no issue.  The
problem is when the server is uncertain whether it is a new open_owner
or not.  In most case of a new open_owner the server will indeed be
uncertain about this, so is this a real annoyance.

> definition of "conflict"?)

"second client" doesn't really imply they are different.  You could then
say "Oh by the way, the second client and the first client can be the same"
without it being a contradiction.  I think some people have called such a
thing (almost an implication but not really because it is rebuttable
without contradiction), an "implicature".

"another client" is stronger evidence.

I had been assuming that conflicts can occur between the delegation and 
opens on the same client.  I think that's the way that existing clients
and servers that support delegation have been implemented (except yours).

Changing that understanding is possible, especially if the spec implies
(or almost implies) otherwise, but I'd like us to think hard about the
implications.  I'd particularly like to hear from those involved in
implementing delegations, any issues they see.

One issue that I can see is that if this is allowed (a Write Open on 
a client that has a Read Delegation) then clients will have to be
very careful about deny modes.  In my model, when you issue the Write
Open to the server, he recalls any delegations and then decides whether 
the write is denied because of Read Opens present on the read delegates,
any of which may deny write.  If the delegation is not recalled in these
circumstances, then the client's processing of a Write open has to include
sending it to the server and also, separately matching it against any of
the Read Open's within the delegation that may deny write.  One bad case
is that if I issue a Read Open (with deny-write) and while that is in
flight, I also issue an Write Open.  If the Read Open results in a read 
delegation and you remove the recall requirement, then I don't think the
server can deny the Write Open (by looking inside the delegation) because
that would impose a requirement on the Read Delegate to promptly propagate
a close of the original open.  So I think the Write Open would have to 
wait for the Read Open response (needs to see if the open happened and
if there is a delegation) and then if the Read Open with deny-write
succeeded
then do a close of Write Open and return SHARE_DENIED to the original 
opener.  Some other deny-write open might fail because of that which
would be annoying, but I guess that is no worse that a deny-write open
which is winds up not being confirmed.  Ugh!  Wait a minute.  If a file
has multiple links how can the client when it issues the Write Open know
that there is a Read Open pending on the same file.  It might not have
seen the filehandle of the target yet.  As I said, we need to think about
the implications of this.      

> delegation before it does the Write Open request?

I don't think you can make that a requirement.  Suppose I issue a Read 
Open and then, before I receive the response, issue a Write Open for
the same file (different open_owner).  From the server's point of view
the client has a read delegation and is a bad guy for not returning
it first but the client has no idea that it does (or perhaps rather
that it will) have a delegation.

> Oh well, I can easily add a Recall to my server, if that's what is
expected,

It's certainly what I expected, and it definitely would be OK, because even
if the spec is OK with the recall not being done, the server may do a recall
when it wants, so it is safe.  You've raised the issue about whether it is
required and I think we need to carefully consider the implications before
deciding it isn't.

---

From: [email-masked]
Date: Mon, 11 Aug 2003 18:26:36 -0400 (EDT)

For now, my server doesn't allow the Read delegation and Write Open case.
(ie. It does the Recall.) For my implementation, it's a one line change
in an 8 line long logical condition in an "if" that decides if there is
a conflict with a delegation:-)

And I'm going to have to think about the other stuff in your post.

Thanks yet again for a good post, rick