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

Steve French smfrench at gmail.com
Tue Jul 17 22:09:58 GMT 2007


On 7/17/07, Trond Myklebust <trond.myklebust at 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


More information about the samba-technical mailing list