Latest leases patchset - getting there !

[Stefan (metze) Metzmacher]

Am 17.11.2014 um 17:26 schrieb Jeremy Allison:
> On Mon, Nov 17, 2014 at 04:42:38PM +0100, Stefan (metze) Metzmacher wrote:
>>
>> I'm not sure I can follow you here...
>>
>> If the sharemode is an oplock, we can only break to level2 or none,
>> so we need to remove both.
>>
>> But the order of my checks was wrong, this should only
>> happen when we have to break anyway.
>>
>> The attached patches on top of everything else passes
>> autobuild for me.
> 
> Fair enough. I'll go through this today.
> 
> The logic here is... complex to say the least :-).
> 
>> I added also a few more tests, which demonstrate that
>> a open with overwrite=true, also break a lease down to none,
>> but only if the lease if not in 'breaking' mode already.
>> (breaking2, while I renamed the old breaking2 to breaking3).
>>
>> The 2nd test breaking4 demonstrates that we should not
>> delay a overwrite opener, if there's only a "RH" lease.
> 
> Great ! I'll write the test for the dynamic share
> path today, and then I think we have full coverage
> (fingers crossed :-).

:-)

Can you also change the timeout test in order to verify that
we still be a async break to none, when the other handle writes.
As an additional verification that the lease is not damaged,
but letting it timing out.

It would also be good to verify this section with a test:

        if (lp_locking(fsp->conn->params) && file_has_brlocks(fsp)) {
                DEBUG(10,("grant_fsp_oplock_type: file %s has byte range
locks\n",
                        fsp_str_dbg(fsp)));
                granted &= ~SMB2_LEASE_READ;
        }

We need to make sure we never grant "W" or WH" leases.

It's also unclear to me why a client shouldn't be able to get a read lease,
when it already has brlocks (and a possible write lease).

Do we have an oplock related test for this already?

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141117/16c8a5e3/attachment.pgp>