Bug 284611

Created attachment 191731 [details]
Purposed patch

(In reply to comment #0)
> Description of problem:
> The mount.nfs[4] mount command have a check that disallows 
> all combinations of the fsc and nosharecache options. This
> check is wrong, since the first instance of this type mount
> is valid. 

What are we saying here Steve?

I understand the "nosharecache" is a noop for the first mount
but could you describe what is expected for second and subsequent
mounts please?

Is/should the non-sharing be propagated and fsc requests failed
or sharing forced, fsc honoured and nosharecache failed?

Ian

> I understand the "nosharecache" is a noop for the first mount
> but could you describe what is expected for second and subsequent
> mounts please?
The seconded occurrence of the mount -o fsc,nosharecache to the 
same server to the same export should fail since the super 
block would not be shared.

> Is/should the non-sharing be propagated and fsc requests failed
> or sharing forced, fsc honoured and nosharecache failed?
I'm not sure what your asking

(In reply to comment #3)
> > I understand the "nosharecache" is a noop for the first mount
> > but could you describe what is expected for second and subsequent
> > mounts please?
> The seconded occurrence of the mount -o fsc,nosharecache to the 
> same server to the same export should fail since the super 
> block would not be shared.

That partly answers the question (there's really only one question).

> 
> > Is/should the non-sharing be propagated and fsc requests failed
> > or sharing forced, fsc honoured and nosharecache failed?
> I'm not sure what your asking

I'm just asking, for example, how would we treat mount -o fsc and
variants of it in the above case, that is where an option isn't
given but is needed to resolve ambiguity for second and subsequent
mounts? So in the case here would we also fail the as the initial
mount superblock is marked not shared?

The point is that, unless we define the semantic behavior of the
various use cases we won't have any yardstick to use to work out
if the NFS client and patches do what's required. If we have a
definition then David can give specific advice on the consequences
of the behavior for fscache.

Ian

I don't think that I understand.  Autofs should just pass along any
mount options that are specified and whether they work is up the NFS
client code, as always.

In this case, "fsc,nosharecache" should work for the first mount.
These two options are somewhat contradictory, but do work together
as long as there isn't a second mount which would need/want to share
the superblock, but can not due to the "nosharecache" option.  The
"need/want" is defined as mounts which share the server IP address
and fsid on the server.  If either the IP address of the server or
the fsid from the server are different, then the mount can use the
fscache, but with a different superblock, and will be treated like
the first mount described previously.

(In reply to comment #5)
> I don't think that I understand.  Autofs should just pass along any
> mount options that are specified and whether they work is up the NFS
> client code, as always.

True, I'm not asking this purely from the point of view
of autofs though.

Ian

Okie doke.  Is there more/different information that is needed?

I believe this was resolved, in RHEL5.1