samba - Dec 2022 - file leases and replacing files

On Fri, Dec 30, 2022 at 08:51:58AM +0300, Michael Tokarev
wrote:
>Well, this is what I suspected initially.
>
>And now we have an interesting situation.
>
>Historically, we setup a software distribution system to multiple
>locations (it worked over dialup too when it was the way to connect).
>Two tarballs of whole thing, compared, made the delta, which is
>distributed to every place. In there, it is applied to the local
>tarball to construct the new tarball. This is a background.
>
>Now, this tarball (including executables and data files) is
>extracted to an empty directory, and a symlink is atomically
>updated to point to the new version. And the old directory
>is deleted.  So this is even worse than modifying certain
>files, - it is something which samba can never notice.
>
>All this is done automatically without user interaction, using
>linux-provided tools.
You're going to have to be much more explicit
because this really doesn't tell me anything
about the client semantics you're expecting
or desire. Or even who the clients are
for that matter.

Where is SMB in this description above ?

Who is the SMB consumer, and what semantics
do you desire for them ?

30.12.2022 09:07, Jeremy Allison via samba wrote:
> On Fri, Dec 30, 2022 at 08:51:58AM +0300, Michael Tokarev wrote:
..
>> Now, this tarball (including executables and data files) is
>> extracted to an empty directory, and a symlink is atomically
>> updated to point to the new version. And the old directory
>> is deleted.? So this is even worse than modifying certain
>> files, - it is something which samba can never notice.
>>
>> All this is done automatically without user interaction, using
>> linux-provided tools.
> 
> You're going to have to be much more explicit
> because this really doesn't tell me anything
> about the client semantics you're expecting
> or desire. Or even who the clients are
> for that matter.
> 
> Where is SMB in this description above ?
> 
> Who is the SMB consumer, and what semantics
> do you desire for them ?
Samba is sharing these files (it's a large application) to
windows clients. It's like a bunch of jar files, to give
an analogy. These files are executed on the client machines
(many of them), whole thing is on a read-only share, run
off it (the same share also contains the executables in a
different directory).

Currently these are all windows10 machines.

The files, most of them anyway, are read into memory on
demand, when/before executing each, they're not kept open
during runtime.

I thought about it some more now, and think the best would
be to "notify" all consumers about the changed files (eg,
to send "oplock break requests" to all involved parties,
speaking in the old terms).

When we initially implemented this, we had oplocks=no for
this share. This made it noticeable slower obviously, but
there were no issues like this (and windows weren't that
sophisticated in this area, ditto for samba).

Maybe turning off share modes will help here as well.
Though if possible, I'd love to find a way to allow
share modes, since the update is rare, and 99.9% of
we can allow caching for sure.

Can one tell smbd to send an oplock break request
somehow?

Thanks!

/mjt