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

From: [email-masked]
Date: Fri, 11 Aug 2006 19:40:25 -0400 (EDT)

> 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....
>From sec. 8.9:

   This checking of share reservations on OPEN is done with no exception
   for an existing OPEN for the same open_owner.

Hmm, yes, I see what you mean. I was thinking of two Opens happenning
concurrently, such that second one will fail, due to a DENY_xxx.
But it doesn't matter if they are the same or different open_owners.

I think I need to go look at my server code. I've got a hunch I only return
NFS4ERR_SHARE_DENIED if they aren't the same open_owner. Oops.

Thanks for pointing this out, rick
ps: btw, the algorithm in Sec. 8.9 of rfc3530 returns NFS4ERR_DENIED, not
    NFS4ERR_SHARE_DENIED. I believe that is an errata?

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

---

From: [email-masked]
Date: Sat, 12 Aug 2006 17:37:45 -0400 (EDT)

[Trond wrote]
> Ah, but you would have to know a priori that you are referring to the
> same file. In filesystems that support hard linking, that is not always
> a given.

Oops, yes. My client does a Lookup before an Open, so it usually knows,
but that could fail if another client does a Link between the Lookup and
Open/create.

[Spencer wrote]
> At one time, the stateid.seqid field was meant to allow the client to
> determine the ordering of the stateids returned from a server and to
> allow the client to determine which stateid is the most recent.
> However, given the discussion we have had about stateid generation
> at the server and the determination that the server does not need
> to change the stateid on state changes, that is unreliable.

I also recall a previous thread that seemed to agree that servers returning
NFS4ERR_OLD_STATEID were just irritating to clients. My server does not
return NFS4ERR_OLD_STATEID for I/O Ops by default.

Maybe for 4.1 servers shouldn't return NFS4ERR_OLD_STATEID, at least for
I/O Ops?

rick

---

From: [email-masked]
Date: Wed, 16 Aug 2006 12:44:06 -0400 (EDT)

> It would likely ease the client implementation if it could count on the 
> server returning a different stateid (seqid++) at each state changing
> operation.  Is there interest in enforcing this stateid behavior so
> the client's can have multiple OPENs in flight?

I believe this is what my server currently does and was what I understood
it was supposed to do with the seqid field of the open_stateid, so it
sounds fine to me.

rick
ps: Oh, and it turns out my server doesn't compare the open_owner name
    when it checks for open DENY_xxx conflicts, so it seems to conform
    to the RFC on that one.