mount options for selectively disabling parts of CIFS Unix Extensions

mount options for selectively disabling parts of CIFS Unix Extensions

[Steve French]

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

Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Steve French]

I would like opinions on how to handle a specific use question ...

if the user has mounted e.g.  \\server1\shareA (e.g. on a Samba
server) using defaults (and thus gotten support for the Unix
Extensions, but then does a second mount trying to disable Unix
Extensions (e.g. "mount -t cifs //server1/shareB /mnt -o nounix" then
what should the result be:

1) mount fails?  If so what return code - there is no easy way to pass
error strings back across mount (get_sb returns an int - a posix
return code)

2) mount succeeds, ignoring the "nounix" option but prints a warning to dmesg

3) mount succeeds but turns off the Unix Capability bits so no Unix
Extension requests are sent on either shareA or shareB (although the
server behavior will still be a little different than if the client
had not negotiated Unix Extensions at all, at least it will be
different unless the session drops and is reconnected at which time
the server will see the Unix Extensions disabled)

4) mount succeeds and no Unix Extension requests are sent on the tree
id for shareB (the requests to shareA are unaffected)

etc.

Ideas?

On 7/16/07, Steve French <smfrench@gmail.com> wrote:
> I have seen various requests from users to disable part of the CIFS
> Unix Extensions on mount

Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Jan Engelhardt]

On Jul 16 2007 18:11, Steve French wrote:
> I would like opinions on how to handle a specific use question ...
>
> if the user has mounted e.g.  \\server1\shareA (e.g. on a Samba
> server) using defaults (and thus gotten support for the Unix
> Extensions, but then does a second mount trying to disable Unix
> Extensions (e.g. "mount -t cifs //server1/shareB /mnt -o nounix" then
> what should the result be:
>
> 1) mount fails?  If so what return code - there is no easy way to pass
> error strings back across mount (get_sb returns an int - a posix
> return code)
>
> 2) mount succeeds, ignoring the "nounix" option but prints a warning to dmesg
>
> 3) mount succeeds but turns off the Unix Capability bits so no Unix
> Extension requests are sent on either shareA or shareB (although the
> server behavior will still be a little different than if the client
> had not negotiated Unix Extensions at all, at least it will be
> different unless the session drops and is reconnected at which time
> the server will see the Unix Extensions disabled)
>
> 4) mount succeeds and no Unix Extension requests are sent on the tree
> id for shareB (the requests to shareA are unaffected)

Vote goes to (4).



	Jan
-- 

Re: [linux-cifs-client] Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Jeff Layton]

On Mon, 16 Jul 2007 18:11:02 -0500
"Steve French" <smfrench@gmail.com> wrote:

> I would like opinions on how to handle a specific use question ...
> 
> if the user has mounted e.g.  \\server1\shareA (e.g. on a Samba
> server) using defaults (and thus gotten support for the Unix
> Extensions, but then does a second mount trying to disable Unix
> Extensions (e.g. "mount -t cifs //server1/shareB /mnt -o nounix" then
> what should the result be:
> 
>
> 1) mount fails?  If so what return code - there is no easy way to pass
> error strings back across mount (get_sb returns an int - a posix
> return code)
> 
> 2) mount succeeds, ignoring the "nounix" option but prints a warning to dmesg
> 
> 3) mount succeeds but turns off the Unix Capability bits so no Unix
> Extension requests are sent on either shareA or shareB (although the
> server behavior will still be a little different than if the client
> had not negotiated Unix Extensions at all, at least it will be
> different unless the session drops and is reconnected at which time
> the server will see the Unix Extensions disabled)
> 
> 4) mount succeeds and no Unix Extension requests are sent on the tree
> id for shareB (the requests to shareA are unaffected)
> 
> etc.
> 
> Ideas?
> 

Following the principle of least suprise, then #4 would be best. If
that's problematic, then I'd suggest just failing the mount outright
with an -EBUSY.

NFS has just gone through a not too dissimilar situation (mounting the
same export twice with different options). It now fails with -EBUSY in
that situation. A new mount option was also introduced (nosharedcache)
that makes it fall back on the previous behavior (not sharing
superblocks between mounts of the same export).

-- 
Jeff Layton <jlayton@redhat.com>

Re: mount options for selectively disabling parts of CIFS Unix Extensions

[J. Bruce Fields]

On Mon, Jul 16, 2007 at 05:40:46PM -0500, Steve French wrote:
> 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 ...

Why do they want to do that?  Just curious.

--b.

Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Steve French]

One example (Samba bug # 2008) is so that Samba will follow symlinks
on the server side (rather than have the client resolve them).


On 7/17/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Mon, Jul 16, 2007 at 05:40:46PM -0500, Steve French wrote:
> > 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 ...
>
> Why do they want to do that?  Just curious.
>
> --b.
>


-- 
Thanks,

Steve

Re: [linux-cifs-client] Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Trond Myklebust]

On Tue, 2007-07-17 at 07:57 -0400, Jeff Layton wrote:
> NFS has just gone through a not too dissimilar situation (mounting the
> same export twice with different options). It now fails with -EBUSY in
> that situation. A new mount option was also introduced (nosharedcache)
> that makes it fall back on the previous behavior (not sharing
> superblocks between mounts of the same export).

Well... The NFS situation was different. NFS has always supported
different mount options for different filesystems. What we were having
issues with was that people were asking to mount the _same_ filesystem
in different places with different mount options.

In CIFS parlance, the equivalent would be to mount \\SERVER\SHAREA\foo
and \\SERVER\SHAREA\bar with different mount options: I'm not sure that
is really what Steve is proposing.

Anyhow, the issue with that is you have to deal with potentially caching
the same file on two different super blocks if, say foo/a and bar/b
happen to be hard linked. We punted on dealing with the dragons hidden
in that sort of issue by requiring that users mount with nosharedcache
if and only if they know that this is safe.

Cheers
  Trond

Re: [linux-cifs-client] Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Steve French]

On 7/17/07, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> In CIFS parlance, the equivalent would be to mount \\SERVER\SHAREA\foo
> and \\SERVER\SHAREA\bar with different mount options: I'm not sure that
> is really what Steve is proposing.
Yes - Or perhaps simply \\server\shareA being mounted twice to two
different paths with different mount options (I also still need to add
the code, as NFS did last year to handle the case where they share a
sb, presumably with the same mount options).   If for nothing else,
being able to do the above will be helpful for Samba server testing -
but I think there are cases in which particular applications work
better with one or the other semantics (as apparently the MacOS guys
run into too).

> Anyhow, the issue with that is you have to deal with potentially caching
> the same file on two different super blocks if, say foo/a and bar/b
> happen to be hard linked. We punted on dealing with the dragons hidden
> in that sort of issue by requiring that users mount with nosharedcache
> if and only if they know that this is safe.
This is an interesting question for cifs in a few ways as well.  CIFS
servers such as Samba can have different clients connected, some with
"windows semantics" and some with "posix semantics" - even for handle
based operations these semamtics differ for whether reads and/or
writes on a locked range can fail.   If \\server\shareA is mounted
twice from the same client with different mount options (in particular
the new "nounix" mount option that I have been coding today, which
disables support for the CIFS Unix Extensions), for reads or writes
from the pagecache it could matter which handle is used - for that
reason, they may have to be treated as distinct inodes or we may have
to forbid a second mount to the same share from the same client unless
a few key mount options ("forcedirectio" and "nounix" e.g.) are the
same on each


-- 
Thanks,

Steve

Re: [linux-cifs-client] Re: mount options for selectively disabling parts of CIFS Unix Extensions

[Trond Myklebust]

On Tue, 2007-07-17 at 17:09 -0500, Steve French wrote:
> This is an interesting question for cifs in a few ways as well.  CIFS
> servers such as Samba can have different clients connected, some with
> "windows semantics" and some with "posix semantics" - even for handle
> based operations these semamtics differ for whether reads and/or
> writes on a locked range can fail.   If \\server\shareA is mounted
> twice from the same client with different mount options (in particular
> the new "nounix" mount option that I have been coding today, which
> disables support for the CIFS Unix Extensions), for reads or writes
> from the pagecache it could matter which handle is used - for that
> reason, they may have to be treated as distinct inodes or we may have
> to forbid a second mount to the same share from the same client unless
> a few key mount options ("forcedirectio" and "nounix" e.g.) are the
> same on each

Uncached i/o still doesn't help you avoid the kernel's use of cached
data. Anything from the references to inode->i_size that litter the
pagecache code to all the dcache references can be a real pain in these
situations.

Cheers
  Trond