Bug 243913 (nosharecache)

Created attachment 156814 [details]
Backported patch from upstream

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.

Fixed in nfs-utils-1.0.9-21.el5

(In reply to comment #6)
> I'm not sure if I understand the comments above. Seems to me we have 2 things 
> to test. Does following test-cases tests this issue?:

They would but I believe you need to use the mount option
"nosharecache" and you need an nfs-utils that understands
the option.

> 
> TEST1:
>   1. run installer and before packages are going to be installed, switch to the 
> console
>   2. # mkdir /mnt/tmp
>   3. # mount -t nfs -o rw server:/path/to/dir
# mount -t nfs -o rw,nosharecache server:/path/to/dir
>   4. # date > /mnt/tmp/my_date
>   5. # mount | grep /mnt/tmp
>   If I'm able to write in point "4." and "5." shows it is mounted rw, then PASS
>   Else FAIL

I'm not clear on how this will behave when the "nosharecache"
option isn't given for the parent. A good test in fact.

> 
> TEST2:
>   1. server# mkdir /tmp/export
>   2. server# mkdir /tmp/export/writable
>   3. server# echo "/tmp/export *(ro,sync,fsid=0)" > /etc/exports
>   4. server# echo "/tmp/export *(rw,sync,nohide)" >> /etc/exports
>   5. client# mkdir /tmp/import
>   6. client# mkdir /tmp/import_rw
>   5. client# mount -t nfs -o ro server:/tmp/export /tmp/import
>   5. client# mount -t nfs -o rw server:/tmp/export/writeable /tmp/import_rw
mount -t nfs -o ro,nosharecache server:/tmp/export /tmp/import
mount -t nfs -o rw,nosharecache server:/tmp/export/writeable /tmp/import_rw

At least this is the way it's been implemented.

Ian

*** This bug has been marked as a duplicate of 209964 ***

Created attachment 186571 [details]
nosharecache is on by default

The patch that added the nosharecache functionality (bz 209964)
caused a large number of problems with (what I
would call) faulty autofs configurations. The part
of that patch that caused the most pain was the
check added to ensure mounts to the same server, 
and export, used the same mount options.

This check broke a large number of Fedora, and upstream
mounting configurations (mostly autofs configs). After
a long discussion on lkml about this, it was deemed 
the nosharecached patch cased a regression. 

So this patch turns basically turns nosharecache
on dynamically when needed. Meaning when the 
kernel determines the there is another mount
to the same server and to the same export but
with different mount option, as new super block
is allocated.

Unfortunately FS-Cache requires super block sharing
with mounts to the same server. So I had to add a
some 'err_on_noshare' detection so mounts that
have the 'fsc' flags, to the same server will fail
with -EINVAL.

removing release note. thanks!

Need some indication of the testing done on this latest patch to this point as
well as some guidance on what testing needs to be done by QE and partners.

I wrote an RHTS regression test for this under /kernel/filesystems/nfs/bz209964.
 It can be run using the client_server workflow.

(In reply to comment #23)
> So how can I test this issue? If I am in Anaconda I can't install anything there
> aso I can't try new package. I tried latest night-build and "nosharecache"
> wasn't supported there. It should be updated in busybox-anaconda to add support
> for the 'nosharecache' option. Now it isn't there. Who can do it?
> 
> If I tried "nosharecahce" in normal installation of rhel it works as expected; 
> see Comment #8.

First you would need to verify that the patch from
comment #16 in included in the kernel being installed.

Once this is done the "nosharecache" option shouldn't
be needed to verify the issue is resolved. Then just
carry out the steps in the opening comment and that
should work ok.

Carrying out the test steps in comment #8 would be a
good idea as well once the nfs-utils package is updated.

It's worth noting that the default behavior has changed
so the issue now becomes verifying that we can force the
sharing of NFS superblocks by using the "sharecache" option,
in which case the tests in comment #8 should have the
opposite effect, preventing the use of different options.

Hope this helps.
Ian

(In reply to comment #25)
> (In reply to comment #24)
> If I understand its like that: 
> 
> nosharecache is by default in mount. ....Comments #16
> ........
> 
> I tried this scenario in latest nightbuild (kernel-2.6.18-45, nfs-utils-1.0.9-23
> and util-linux-2.13-0.45)

Think we've been a little hasty.
I can't see that patch in the kernel cvs yet.

Ian

in 2.6.18-48.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0651.html

*** Bug 380171 has been marked as a duplicate of this bug. ***