On 3/3/2021 11:28 AM, Aurélien Aptel wrote:
Hi Tom,
Thanks for taking a look.
Tom Talpey <tom@xxxxxxxxxx> writes:
On 3/2/2021 10:48 AM, Aurélien Aptel wrote:
I'd suggest removing this sentence. It doesn't really add anything to
the definition.
OK.
This is discussing the scenario where a process on the server performs
an flock(), right? That's perhaps confusingly special. How about
This is about clients. Let's say the same app is running on 2 different
Linux system that have the same Windows Server share mounted.
The scenario is those 2 app instances use the same file on the share and
are trying to synchronize access using flock().
Pre-5.5, CIFS flock() is using the generic flock() implementation from
the Linux VFS layer which only knows about syscall made by local apps
and isn't aware that the file can be accessed under its feet from the
network.
I don't fully understand your response. What does "knows about syscall
from local apps" mean, from a practical perspective? That it never
forwards any flock() call to the server? Or that it somehow caches
the flock() results, and never checks if the server has a conflict
from another client?
In 5.5 and above, CIFS flock() is implemented using SMB locks, which
have different semantics than what POSIX defines, i.e. you cannot ignore
the locks and write, write() will fail with EPERM. So this version can
be used for file sync with other clients but works slightly
differently. It is a best-effort attempt.
I think we're agreeing here. Let's figure out the other question before
deciding.
Bottom line, I think it's important to avoid statements like "same" or
"different". Say what it does or does not do, and leave such questions
to other sources.
Tom.
Does this clarification changes anything to your suggestions?
"In Linux kernels up to 5.4, flock() is not propagated over SMB. A file
with such locks will not appear locked for remote clients."
"protocol, which provides mandatory locking semantics."
OK. As it turns out, there is actually a 'nobrl' mount option to get back
pre-5.5 behavior. I'll mention it and use your suggestions in v2.
Cheers,
