[PATCH] locks: breaking read lease should not block read open

J. Bruce Fields bfields at fieldses.org
Wed Jul 20 18:07:58 MDT 2011


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.


More information about the samba-technical mailing list