On Fri, Jun 10, 2011 at 09:48:59AM -0400, J. Bruce Fields wrote: > On Fri, Jun 10, 2011 at 09:56:49AM +0200, Volker Lendecke wrote: > > Without having looked too deeply, just let me point out that > > Samba here has a plain flaw. Early Linux Kernel versions > > that we programmed against did not properly support read > > only leases, so we did not implement that initially. If I > > remember correctly we never got around to finally do it once > > it became available. Eventually we will probably, as read > > only leases are a pretty important feature to present to > > CIFS clients. > > Thanks, I didn't know that. (Or I did, and I forgot.) > > When you *do* implement that, is there any chance you'd have this need > to be able to downgrade to a read lease in the case of a conflict? So it's a question about the protocols samba implements: - Do they allow an atomic downgrade from an exclusive to a shared oplock? (Or to a level 2 oplock, or whatever the right term is). - If so, can that happen as a response to a conflicting open? (So, if you're holding an exclusive oplock, and a conflicting open comes in, can the server-to-client break message say "now you're getting a shared oplock instead"? Or is the client left without any oplock until it requests a new one?) I'm not sure how to approach the lease code. On the one hand, I've never seen any evidence that anyone outside Samba and NFSv4 has ever used it, and both currently make extremely limited use of it. So we could probably get away with "fixing" the lease code to do whatever both of us need. On the other hand, I don't know how to figure out what exactly Samba will actually need. And the conservative thing to do would be to leave leases alone. So maybe I'm better off with a new "NFSv4 delegation lock type" that does exactly what I need it to, and that's only available from inside the kernel for now. Then later if it proves useful to Samba as well, we could figure out how to export an interface for it to userspace. I'm not sure. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
