Re: [PATCH v4] flock.2: add CIFS details

["Aurélien Aptel" <aaptel@suse.com>]

Tom Talpey <tom@talpey.com> writes:

> On 3/11/2021 5:11 AM, Aurélien Aptel wrote:
>> "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com> writes:
>>> I agree with Tom.  It's much easier to read if you just say that 'nobrl'
>>> torns off the non-locale behaviour, and acts as 5.4 and earlier kernels.
>>>    Unless there's any subtlety that makes it different.  Is there any?
>> 
>> nobrl also makes fnctl() locks local.
>> In 5.4 and earlier kernel, flock() is local but fnctl() isn't.
>> 
>>> BTW, you should use "semantic newlines":
>> 
>> Ok, I'll redo once we agree on the text.
>
> I wonder if it's best to leave the nobrl details to the mount.cifs
> manpage, and just make a reference from here.
>
> Another advantage of putting this in a cifs.ko-specific manpage
> is that it would be significantly easier to maintain. The details
> of a 5.4-to-5.5 transition are going to fade over time, and the
> APIs in fcntl(2)/flock(2) really aren't driving that.

I was trying to write in the same style as the NFS details just above (see
existing man page). Give basic overview of the issues.

> If not, it's going to be messy... Aurélien is this correct?
>
> cifs.ko flock()
> - local in <= 5.4
> - remote by default in >= 5.5
> - local if nobrl in >= 5.5
>
> cifs.ko fcntl()
> - remote by default in X.Y
> - local if nobrl in X.Y

Correct.

> Not sure what the value(s) of X.Y actually might be.

AFAIK fcntl() was always remote by default.
And nobrl was added in 2.6.15 (15 years ago). I wouldn't bother
mentionning X.Y, it's already complex enough as it is.

> It seems odd that "nobrl" means "handle locking locally, and never
> send to server". I mean, there is always byte-range locking, right?

Yes the option name can be confusing. Byte-range locking is always
possible, but with "nobrl" it's local-only.

> Are there any other options or configurations that alter this?

I've taken another long look at the cifs.ko and samba code. There are
many knobs that would make an accurate matrix table pretty big.

* If the mount point is done on an SMB1+UNIX Extensions
  connection, locking becomes advisory. Unless
  forcemandatorylock option is passed. This will eventually be
  implemented for SMB3 posix extensions as well (I've started a
  thread on the samba-technical mailing list).
* If cifs.ko can get guarantees (via oplocks or leases) that it is the
  only user of a file, it caches read/writes but also locking
  locally. If the lease is broke then it will send the locks.
  The levels of caching cifs.ko can do can be changed with the cache
  mount option.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)