breaking leases on metadata changes

[J. Bruce Fields]

On Sat, Sep 24, 2011 at 08:36:04PM +0200, Stefan (metze) Metzmacher wrote:
> Hi Bruce,
> 
> > So there's this longstanding problem that read leases should really be
> > broken on anything that changes an inode's metadata or any change to the
> > set of links pointing to the inode.
> > 
> > (Cc'ing samba-technical for confirmation of that statement from Samba's
> > point of view....)
> > 
> > So we need mutual exclusion between read leases and link, unlink,
> > rename, etc.
> 
> As far as I know oplocks in SMB only care about content
> and attribute only opens (without the READ/WRITE access bits) doesn't
> break oplocks.

Thanks for looking into this!

Just wandering around msdn (but not having to background to know what
really applies)....  The discussion of "Level 2 Opportunistic Locks"
(which is what I assume you'd be using read leases to implement) at
http://msdn.microsoft.com/en-us/library/aa365713(v=VS.85).aspx says such
an oplock "allows the client to perform read operations and obtain
fileattributes using cached or read-ahead local information".  Which
suggests the oplock also covers attributes?

But I'm probably not reading the right thing.

Is it possible to get any sort of documentation or test results or
confirm the behavior here?

> So changing the modification time of a file should not break the oplock.
> 
> I think link and rename doesn't break oplocks, while unlink would.
> 
> But Samba requirements may change for SMB 2.2 support with directory leases.
> We're currently exploring what the details are.

Well, presumably you'll need to keep supporting the old semantics as
well, regardless of what the new protocol may do.

Anyway, if this is all correct then it sounds like v4 read delegations
and level 2 oplocks may be more different than I'd thought.

In which case I'm probably better off leaving leases alone for now and
defining a new lock type for v4 delegations.  Which could be exposed to
userspace later as well if it turned out to be useful to someone.

That's not to rule out fixes to lease behavior to work better for Samba
if there are any that would make sense.

--b.