I have seen various requests from users to disable part of the CIFS
Unix Extensions on mount (in some cases fall back to the more
primitive Windows behavior) but am wondering how far down this line of
thought I should go ... how many mount options to add to cifs and is
there a precedent in other file systems. Does NFS have this type of
problem - how to disable similar protocol features (some of which are
negotiated per-session and some per-export)
Currently negotiating the Unix Extensions (e.g. with a Samba server) provides:
1) better symlink support
2) the real UID/GID/mode can be returned on lookup rather than emulated
(even with Unix Extensions negotiated current cifs already does
allow "uid" and "gid" to be overridden on mount to help with the
common case in which the server and client's uid's do not match)
3) better semantics for byte range locking
4) better support posix path names (a few characters like : and *
would otherwise be reserved)
5) better unlink semantics
6) faster mkdir
7) support for posix acls
The Unix Extensions are negotiated at first connection to the server,
and additional ones are set (e.g. posix path support, and posix
locking support) on the newly mounted export (ie the cifs "tree
connection" via Trans2 SetFSInfo on the share we just mounted)
Currently, to disable the Unix Extensions requires (before the first
mount to the server):
"echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled"
which is awkward if you already have the share mounted, and it is also
annoying to some users to have to remember to flip this flag off and
on depending on which server they are mounting to. To satisfy that
requirement I was planning on adding a "nounix" mount option (any
suggestions for a better option name) which just turns off Unix
Extensions for the mount we are about to attempt.
The only two mount options we currently provide for selectively
enabling the Unix Extensions are for turning off support for posix
path names and posix acls. Do we need to allow mount options for
disabling any of the currently support SetFSInfo (CIFS Unix
Extensions) options (currently only support for the last two are not
yet in the client)
#define CIFS_UNIX_FCNTL_CAP 0x00000001 /* support for fcntl locks */
#define CIFS_UNIX_POSIX_ACL_CAP 0x00000002 /* support getfacl/setfacl */
#define CIFS_UNIX_XATTR_CAP 0x00000004 /* support new namespace */
#define CIFS_UNIX_EXTATTR_CAP 0x00000008 /* support chattr/chflag */
#define CIFS_UNIX_POSIX_PATHNAMES_CAP 0x00000010 /* Allow POSIX path chars*/
#define CIFS_UNIX_POSIX_PATH_OPS_CAP 0x00000020 /* Allow new POSIX path
based calls
including posix open and posix unlink */
#define CIFS_UNIX_LARGE_READ_CAP 0x00000040 /* support reads >128K (up
to 0xFFFF00 */
#define CIFS_UNIX_LARGE_WRITE_CAP 0x00000080
--
Thanks,
Steve
-
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
