Subject: RE: [nfsv4] Parallel open support

From: [email-masked]
Date: Tue, 19 Sep 2006 16:34:08 -0400 (EDT)

>> Can't a client do that now, just by using different openowner names?
>> (ie 1 per thread or whatever) I think all this does is replace increased
>> storage usage for more openowners with increased storage usage for more
>> Open stateids?
>
>No! That screws up byte range locking semantics. Byte range lock state
>is currently a triplet: <filehandle,open_owner,lock_owner> because of
>the open_to_lockowner stuff. If you have two different open_owners, then
>their locks will always conflict, even if the lock_owner is the same.

Well, that's not quite the way I see it. Although there is a relationship
formed between a lock_stateid and an open_owner created via open_to_lock_owner
which defines what locks must be unlocked before Close (and I mentioned that
I wouldn't mind that check being dropped in the previous post), I don't
see open_owner as part of a triplet that checks for a lock conflict. My
server checks for a lock conflict via:
	if same_client and lock_owner4 len same and
		!bcmp(lock_owner4-of-this-stateid, lock_owner4-of-other-lock,
		      lock_owner4-len)

In other words, if it is the same client and same lock_owner4 byte array
(not stateid), then I don't consider it a conflict.

This is different from what my code does when it checks I/O Ops for
mandatory locking, but I think my current code isn't necessarily correct.
(Recent response to Dave's post on "1)" vs "2)" for mandatory locking.)

Now, if we assume that the requirement for checking for outstanding locks
remains a part of Close...
I do agree that a client that does byte range locking (there might
be a client that never does byte range locking and therefore doesn't care)
must be very careful how it uses open_owners so that it doesn't
get bit by a server reply NFS4ERR_LOCKED for Close.

rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 19 Sep 2006 18:14:51 -0400

> (not stateid), then I don't consider it a conflict.

So consider the case where you have 2 open_owners, O1 and O2. They are
both using the same lock_owner string.

Do the two open_to_lockowner calls create 2 different sequence id
streams on your server?

 - if not, how do you ensure that LOCK/LOCKU is ordered w.r.t. CLOSE on
either O1 or O2?

 - if, OTOH, it does, how do you ensure that LOCK/LOCKU from stream1 is
ordered w.r.t. LOCK/LOCKU from stream2?