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