Subject: Re: [nfsv4] parallel opens in NFSv4.1 ?

From: [email-masked]
Date: Fri, 11 Aug 2006 15:46:46 -0400 (EDT)

> I don't understand why you can't solve this problem in 4.0 by just
> creating more openowners as needed on the fly.
> 
> Lockowners have an additional meaning (they are also used to determine
> when there is a locking conflict) which prevents you from creating new
> ones arbitrarily.  I didn't think there was a similar problem with open
> owners.  Am I missing something?

Assuming the client is always using DENY_NONE, I believe it is up to the
client implementor w.r.t. how many open_owners they use. To me, the downside to
creating lots of them seems to be:
- some (most ?) servers will force confirmation of new open_owners (nfsv4.0)
  and this adds a round trip rpc that must be serialized for that
  open_owner (To avoid doing this, the server must know it has never seen
  the open_owner before, I think?)
- more client side overhead keeping track of all the open_owners

Does that cover it? rick

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 11 Aug 2006 16:15:37 -0400

And note, a session means the server won't require the confirm,
turning OPEN into a simple request/reply in 4.1. So, this collapses
to your second downside.

I think this downside is actually a good tradeoff, the client can
decide to issue parallel opens by creating new open_owners. If
it doesn't want to, it doesn't have to (and still gets the one-roundtrip
benefit).

Tom.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Aug 2006 17:13:26 -0400

On Fri, Aug 11, 2006 at 03:46:46PM -0400, [email-masked] wrote:
> Assuming the client is always using DENY_NONE

Does it matter even then?  I thought that a deny mode affected all
subsequent opens, whether done by the same open owner or not.  I may be
confused....

--b.