On 3/11/2021 12:13 PM, Aurélien Aptel wrote:
Tom Talpey <tom@xxxxxxxxxx> writes:
On 3/11/2021 5:11 AM, Aurélien Aptel wrote:
"Alejandro Colomar (man-pages)" <alx.manpages@xxxxxxxxx> 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.
I vote for simplicity! Especially on the fcntl(2) page in question.
Totally agree on not mentioning 2.6.x in a current manpage.
* 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).
NO SMB1 discussion! Any manpage update should not add discussion of
an obsolete nonsecure deprecated protocol, and should definitely not
passively encourage its consideration.
* 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.
I think this is relevant to some sort of smb(7) manpage, but is much
too detailed and subtle for a paragraph summary in fcntl(2).
To be more clear, my updated thinking is to mostly drop the details
in the closing sentence:
The nobrl mount option (see mount.cifs(8)) turns off fnctl(2)
and flock() lock propagation to remote clients and makes flock() locks
advisory again.
and simply state (perhaps)
"Remote and mandatory locking semantics may vary with SMB protocol,
mount options and server type. See mount.cifs(8) for additional
information."
Tom.
