Subject: Re: stateid question

From: David Robinson <[email-masked]>
Date: Thu, 14 Oct 1999 15:05:13 -0700 (PDT)

> 1/ But why *would* a client resend the same lock request?  It must
>    remember that it already has the lock, so it wouldn't (or needn't) do it
>    intentionally, and seqid, or changing stateid protects against RPC
>    level resends.

Primarily because there are system APIs that explicitly allow this
to occur without failure.

> 3/ I accept that it might be useful to have some idea who has a lock
>    when a test shows that there is a lock.  But does the "who" need to
>    involve some component of the NFS client?  Is it not enough just to
>    know which NFS client has the lock?  
>    The only senario that I can imagine where you want to know "who"
>    has a lock is if you are a sysadmin chasing down bugs (and I've
>    been there). In that case, you ask the server which client has the
>    lock, and what the filehandle will look like, and then ask that
>    client which process (or thread or whatever is meaningful on the
>    client) has locks on that filehandle.

Ignoring the above issue, I originally proposed removing the test
operation.  A large crowd screamed foul as there exist standard
interfaces that require this information.  The client can fake it
but not very well.

	-David