Bug 284611 - Bad fsc,nosharecache check in mount.nfs and mount.nfs4
Bad fsc,nosharecache check in mount.nfs and mount.nfs4
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils (Show other bugs)
5.1
All Linux
medium Severity low
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-10 10:12 EDT by Steve Dickson
Modified: 2008-04-26 08:21 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHEL5.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-26 08:21:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Purposed patch (674 bytes, patch)
2007-09-10 11:46 EDT, Steve Dickson
no flags Details | Diff

  None (edit)
Description Steve Dickson 2007-09-10 10:12:50 EDT
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:
Comment 1 Steve Dickson 2007-09-10 11:46:07 EDT
Created attachment 191731 [details]
Purposed patch
Comment 2 Ian Kent 2007-09-11 07:59:21 EDT
(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
Comment 3 Steve Dickson 2007-09-11 08:50:30 EDT
> 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
Comment 4 Ian Kent 2007-09-11 10:11:32 EDT
(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
Comment 5 Peter Staubach 2007-09-11 10:51:51 EDT
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.
Comment 6 Ian Kent 2007-09-11 11:03:12 EDT
(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
Comment 7 Peter Staubach 2007-09-11 11:25:10 EDT
Okie doke.  Is there more/different information that is needed?
Comment 8 Steve Dickson 2008-04-26 08:21:33 EDT
I believe this was resolved, in RHEL5.1

Note You need to log in before you can comment on or make changes to this bug.