Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust <trond.myklebust@fys.uio.no>]

to den 11.08.2005 Klokka 10:06 (-0400) skreiv Trond Myklebust:

> The NFSv4 spec explicitly states that
> 
>   When a client has a read open delegation, it may not make any changes
>   to the contents or attributes of the file but it is assured that no
>   other client may do so.  When a client has a write open delegation,
>   it may modify the file data since no other client will be accessing
>   the file's data.  The client holding a write delegation may only
>   affect file attributes which are intimately connected with the file
>   data:  size, time_modify, change.
> 
> so NFSv4 cannot currently support this behaviour. If CIFS supports it,
> then maybe we have a case for going to the IETF and asking for a
> clarification to implement the same behaviour in NFSv4.

Note: I'm not saying that this means we _must_ implement the current
behaviour in leases. If CIFS allows the server to hand out read oplocks
when the client opened the file with a write share, then NFSv4 can
simply deal with the difference in semantics by just never requesting a
read lease in that situation.
That said, if CIFS has the same semantics as NFSv4, then why allow the
aberrant case?

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/