Bug 277891

nfs does not define a remount_fs operation in its super_operations because
of which remount of nfs shares will not work for operations other then
generic mount options.
http://nfs.sourceforge.net/#faq_d11

When we try to remount nfs shares with options such as actimeo, the option
is not applied. But the mount syscall in these cases returns a success.

The customer requests that if options which are not going to be effective
are passed when remounting nfs shares, the operation should fail and an
error propagated to the userland mount command. The current setup causes
problems when the new mount options are written to the mtab file even
though the options are  not effective and the mount -v cannot be trusted.
The customer in such cases has to grep through /proc/mounts to see if the
command succeded.    

"mount" should return a non-zero exit code if anything didn't work when
attempting to perform the requested actions.

It looks like this will require us to add a remount_fs opetation to
nfs_sops. This doesn't seem to exist upstream.



This event sent from IssueTracker by sprabhu 
 issue 126915

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

actually...this doesn't look too tough to implement upstream (or for RHEL5). We
already have a nfs_compare_mount_options() function that tells us if there are
different options.

I suppose we can just wrap that and have remount_fs error out if that function
returns false. I'm not sure what error is appropriate in this situation though.

Still, it's not likely that this will go upstream before the 5.2 deadline so 5.3
is probably appropriate...

It's a little trickier than that though...

It appears that mount.nfs doesn't fully populate the nfs_mount_data structure on
a remount. In particular, things like the address and family are missing. This
might not a problem for text based mounts, but fedora doesn't have those yet.

...so to fix this right, we'll probably have to fix mount.nfs too, or break up
the comparison functions so that the missing info isn't needed.

Created attachment 298503 [details]
proposed upstream patch

Proposed upstream patch for this. Just have all remount attempts fail with
-ENOSYS.

I was considering trying to compare mount options and allowing it to succeed if
none had changed, but that turns out to be pretty complex and I'm not sure
there's much value in it.

The patch in comment #9 was shot down by the upstream maintainer. It would make
it so that mounting with '-o ro,remount' would fail when it currently would succeed.

There are significant problems with making this work, however, particularly with
binary mount options which are what is used in RHEL4 and 5.

For instance, suppose we have a mount with options like this:

rw,rsize=4096

...and then I come along and do this:

mount -o remount,ro ...

...mount.nfs will fill out a new option struct and will leave rsize blank (since
I didn't specify it). If I then compare my new mount options with the existing
ones, they'll appear to be different (since my old rsize was non-default), and
the mount would have to be denied.

For this reason, I'm going to devel_nak this case. I don't think it's feasible
that we can actually do this in any existing RHEL release while maintaining ABI. 

RHEL6 and beyond should have string-based mount options. With that, this may be
more feasible, though userspace mount.nfs will need to be able to parse
/proc/mounts or /etc/mtab and merge the existing mount options with any
specified on the command line.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.