Subject: RE: [nfsv4] Parallel open support

From: [email-masked]
Date: Wed, 20 Sep 2006 12:49:45 -0400 (EDT)

> So basically, your client sets up a single lockowner/open_owner
> association, just like the rest of us do.

Nope, my client does basically what I think Mike is describing. For example:
- process P1 opens "foo" using open_owner "P1", gets OpenStateid1
  using open_owner_seqid_P1
- process P1 forks child P2
- process P2 does a byte range lock on inherited open file descriptor for
	"foo" using open_to_lock_owner with lock_owner "P2", OpenStateid1 and
	open_owner_seqid_P1 (LOCK Op using open_to_lock_owner arg)
	- gets LockStateid3 with LockStateid3-seqid initialized to the
	  value given in the open_to_lock_owner arg.
- process P2 opens "foo" using open_owner "P2", gets OpenStateid2
  using open_owner_seqid_P2
- process P2 does a byte range lock on this file descriptor, using
	open_to_lock_owner with lock_owner "P2", OpenStateid2 and
	open_owner_seqid_P2 (LOCK Op with open_to_lock_owner arg)
	- gets LockStateid4 with LockStateid4-seqid initialized to the
	  value given in the open_to_lock_stateid arg.
- P2 will now be doing byte range locking on "foo" using both
	LockStateid3 and LockStateid4 using the respective
	LockStateid3-seqid or LockStateid4-seqid

I expect the server to never consider these LOCK Ops conflicting, since
they are all being done by lock_owner "P2".

It just so happens that...
I don't close either file descriptor until P2 exits (because of write
behinds in the buffer cache that might be associated with any Open) and
I UNLOCK any extant byte range locks on either descriptor before doing
the CLOSEs.

> So my question stands: what is the point of pretending that locking
> state is independent of the open_owner?
That depends on whether by "locking state" you mean "lock_owner" string
or lock_stateid? (I only worry about the relationship when I need to CLOSE
and I consider it a realtionship between OpenStateid and the LockStateid(s)
associated with that OpenStateid via the open_to_lock_owner case of the LOCK
Op. done on that OpenStateid.)

rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 20 Sep 2006 13:24:55 -0400

> Op. done on that OpenStateid.)

So how do you deal with situations like the following:

2 threads, both part of the same process (and therefore sharing the same
lock_owner). Due to an application programming error, both launch a
conflicting lock request at the same time.

Thread 1				Thread 2
========				========
fd1 = open("foo",O_RDONLY);
					fd1 = open("foo", O_WRONLY);

fcntl(fd1, F_SETLK,			fd2 = fcntl(fd2, F_SETLK,
	{ F_RDLCK,					{ F_WRLCK,
	  SEEK_SET,					  SEEK_SET,
	  0, 100,					  50, 100,
	});						});

Will your client order these requests on the wire? How?

If the requests are unordered, how does it figure out what type of lock
was just set on this file?

Note that if the client gets the type of lock wrong above, then reboot
recovery quickly becomes a nightmare: imagine if the client recovers a
write lock, when it originally held a read lock on the server.

Cheers,
  Trond