Messages in this thread | | | Subject | Re: fcntl(F GETLEASE) semantics?? | From | Trond Myklebust <> | Date | Thu, 11 Aug 2005 10:06:31 -0400 |
| |
to den 11.08.2005 Klokka 15:22 (+0200) skreiv Michael Kerrisk:
> As noted already, I don't know much of CIFS and SAMBA. > But are you saying that it is sensible and consistent that > "a process can open a file read-write, and can't place a > read lease, but can place a write lease"?
It is just as "sensible and consistent" as being able to open the file read-write and being able to place a read lease but not a write lease. What is your point?
Make no mistake: this is not a locking protocol. It is implementing support for a _caching_ protocol.
> This is precisely the point of the problem. Stephen > Rothwell, and Matthew Wilcox seem to be saying that > the last bit is not the case.
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.
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/
| |