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

Hi!

I'm trying to understand how various ways to grant a file lease to (windows)
clients
works. Especially in context when files are being modified locally on the linux
filesystem.

For example, there's this wording in man smb.conf:

  kernel share modes
   ...
      Kernel share modes provide a minimal level of interoperability with
      local UNIX processes and NFS operations by preventing access
      corresponding to the SMB share modes. This requires a file system
      specific VFS module with proper support.

      This parameter defaults to no. Setting it to yes requires a file
      system module that supports file system sharemodes, otherwise
      attempts to access files will fail with a sharing violation.

So there are a few questions in there. First of all, am I reading it
right, the result is that local processes can't modify the locked
files? To be fair, I have never seen this happen, to the point when
I don't think this is possible. Unless, ofcourse, the local linux
application which modifies files locally, does some locking like
flock/fcntl.

Also it is not clear which VFS module is needed in this case.

There's another parameter, `change notify', but it is also not
clear when/how this feature is used. From the parameter name it
smells like samba will be notifying client about file changes
on the server, but it looks like the client have to "subscribe"
to the changes somehow first?

Which mechanisms samba has to tell (windows) clients about file
changes on the share? Does something of that work with file
leases granted to clients?

What I'm trying to understand is how I should configure things and
how I should do these things in order to tell the clients about
changed files on server but still to allow clients to cache/lease
the files for better performance.

Browsing the 'net it looks like this topic is commonly misunderstood.

Thanks,

/mjt

On 20/01/2023 09:10, Michael Tokarev via samba wrote:
> Hi!
> 
> I'm trying to understand how various ways to grant a file lease to 
> (windows) clients
> works. Especially in context when files are being modified locally on 
> the linux
> filesystem.
> 
I didn't bother reading further, because you shouldn't locally modify 
files on a Samba share. This is because Samba has no way of knowing that 
said files have been modified locally.

Rowland

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".

Locking (sharemodes): we used to leverage Linux support for mandatory 
flock() locks (LOCK_MAND) to "store" and let the kernel enforce access
restrictions for local access, but unfortunately the kernel support got 
removed because it was buggy:

<https://github.com/torvalds/linux/commit/f7e33bdbd6d1bdf9c3df8bba5abcf3399f957ac3>

We still have VFS hooks for this but iirc the only filesystem that 
supports this via the VFS interface is GPFS.

Hope this helps somewhat.
-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba
-------------- 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/20230120/8ff07613/OpenPGP_signature.sig>