If we remove the check on (roughly) line 647 of fs/cifs/file.c for the
experimental flag (/proc/fs/cifs/Experimental) - we will do posix style
advisory locking (remotely) to Samba and any other current servers which
implement the POSIX protocol extensions to cifs - rather than map to
mandatory locks as before. This is the correct default behavior now
that the code has been out there a while and tests out ok.
But would this ever need to be turned off (ie different options than are
available now)?
1) default
- POSIX advisory locking if server claims support for
CIFS_UNIX_FCNTL_CAP in its CIFS Unix Extensions capability
- otherwise map advisory locks to mandatory locks
2) if "nobrl" mount option, the client only sets/gets/enforces byte
range locks locally (does not send them to the server) which is the best
we can do for some important (albeit oddly coded) apps (which e.g. use
different file handles to write than the one they used to get the lock)
when run to Windows servers
3) turn off Unix extensions (/proc/fs/cifs/LinuxExtensionsEnabled)
which has the effect of turning off posix byte range locking, but also
symlinks and a few other things only supported when the Unix Extensions
are negotiated
Is there a need for another cifs mount option (to allow someone to turn
off posix advisory locking on the mount - and use manadotory - but still
use the rest of the CIFS Unix/POSIX protocol extensions? Although
there is an sb flag MS_MANDLOCK (which mount.cifs sets), I don't think
that using MS_MANDLOCK helps much - and we should probably turn it off
when the server supports mandatory locks.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
