samba - Jan 2023 - oplocks, kernel oplocks, kernel share modes, .. - how it all works?

20.01.2023 14:49, Ralph Boehme via samba wrote:
> I don't have that much time to explain this in glory detail, but here
are a few pointers.
> 
> There are three different apsects:
> 
> - locking in the Windows sharemode flavor
> - file change notify
> - client side caching via oplocks/leases
> 
> File change notify is fully supported and will detect local changes via
inotify on Linux. Iirc there are some caveats like recursive change notify but
> that doesn't seem to be a production problem as Windows clients
typically don't make use of this feature.
> 
> Client side caching (oplocks/leases): somewhat limitted support by enabled
"kernel oplocks". Kernel oplocks don't work with SMB2 Leases, so
you're
> restricted to SMB1 oplocks. Cf man smb.conf "kernel oplocks".
Hi Ralph!

I'm testing this and wonder if something's not working where it should,
or maybe I don't understand something again.

Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock      SharePath 
Name   Time
62347        1060       DENY_WRITE 0x120089    RDONLY     LEASE()     /ws/ws    
one    Tue Jan 24 11:32:00 2023
62347        1085       DENY_NONE  0x120089    RDONLY     LEASE()     /ws/ws    
two    Tue Jan 24 11:50:12 2023

Here we've two files open, with kernel oplocks = yes (hence it is LEASE(), -
before I enabled kernel oplocks, it was LEASE(RH) or LEASE(RWH)).

When I modify file "two" on linux, there's nothing goes on at all,
samba
does not even notice this.  I suspect this is a file cached on the client,
so effectively samba does not tell the client to drop or revalidate the
cache.

On the other hand, when I modify file "one", samba does notice
it's been
modified, - it looks like this is done using inotify mechanism, not
file lease mechanism, because it does not receive any signals, but does
receive a message over inotify FD.  Smbd when sends a message to client,
which apparently tells it to re-read the directory which it does. But
again, the file stays locked the same as before, and the client does
not notice this file is changed.

I modify it by using `cp' in both cases.

So there are 2 questions:

  1) why I don't see inotify working in case of file "two". I
guess it
   can be because the client is not subscribed to changes for this file.

and most important,

  2) where's the kernel oplocks in action? For this, I'll try to strace
   smbd for a bit more, hopefully I will see the fcntl calls in there.

Also, it looks like inotify can be used to break oplocks/leases *too*,
with or without kernel oplocks, Has this been considered?

Thanks!

/mjt

On Tue, Jan 24, 2023 at 12:38:29PM +0300, Michael Tokarev via samba
wrote:
>
>Here we've two files open, with kernel oplocks = yes (hence it is
LEASE(), -
>before I enabled kernel oplocks, it was LEASE(RH) or LEASE(RWH)).
Kernel oplocks do not support SMB2+ LEASES. So you're
just seeing old SMB1-style oplocks.

What Samba version is this? This:
> LEASE() 
... looks broken: the handle oplock/lease state claims to be a lease, 
which means the client didn't request an oplock but a lease which should 
not have happened in the first place, because the global leases 
capabiltiy is not signaled by the server when kernel oplocks are enabled.

I assume this is 4.17? That saw substantial changes in the core open 
handling, I'm worried that some of the subtle oplock/lease handling was 
broken by those changes.

-slow


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20230124/b298b96d/OpenPGP_signature.sig>