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. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1.mount -o fsc,nosharecache server:/export /mnt 2. 3. Actual results: All mounts fail. Expected results: The first instance of the combination of mounts should work. Other mounts, to the same server, should fail. Additional info:
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