Bug 243913 (nosharecache) - NFS Client R/O in anaconda preinstall environment
Summary: NFS Client R/O in anaconda preinstall environment
Alias: nosharecache
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact:
Keywords: Regression, Reopened
: 380171 (view as bug list)
Depends On: 209964
TreeView+ depends on / blocked
Reported: 2007-06-12 17:57 UTC by Steve Dickson
Modified: 2007-11-30 22:07 UTC (History)
19 users (show)

Fixed In Version: RHBA-2007-0651
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-07 17:15:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backported patch from upstream (5.79 KB, patch)
2007-06-12 18:00 UTC, Steve Dickson
no flags Details | Diff
nosharecache is on by default (9.76 KB, text/x-patch)
2007-09-04 20:08 UTC, Steve Dickson
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0651 normal SHIPPED_LIVE nfs-utils bug fix and enhancement update 2007-10-30 16:19:49 UTC
Red Hat Product Errata RHBA-2007:0959 normal SHIPPED_LIVE Updated kernel packages for Red Hat Enterprise Linux 5 Update 1 2007-11-08 00:47:37 UTC

Comment 1 Steve Dickson 2007-06-12 18:00:00 UTC
Created attachment 156814 [details]
Backported patch from upstream

Comment 2 RHEL Product and Program Management 2007-06-12 18:04:03 UTC
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

Comment 3 Steve Dickson 2007-06-12 20:43:02 UTC
Fixed in nfs-utils-1.0.9-21.el5

Comment 7 Ian Kent 2007-08-27 10:20:34 UTC
(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.


Comment 12 Steve Dickson 2007-08-30 19:43:02 UTC

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

Comment 16 Steve Dickson 2007-09-04 20:08:20 UTC
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.

Comment 18 Don Domingo 2007-09-04 23:38:10 UTC
removing release note. thanks!

Comment 20 Jay Turner 2007-09-05 12:49:01 UTC
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.

Comment 21 Jeff Moyer 2007-09-05 17:31:15 UTC
I wrote an RHTS regression test for this under /kernel/filesystems/nfs/bz209964.
 It can be run using the client_server workflow.

Comment 24 Ian Kent 2007-09-11 03:13:24 UTC
(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.

Comment 26 Ian Kent 2007-09-12 15:47:53 UTC
(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.


Comment 29 Don Zickus 2007-09-18 19:23:48 UTC
in 2.6.18-48.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 37 errata-xmlrpc 2007-11-07 17:15:40 UTC
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.


Comment 38 Jeff Layton 2007-11-13 18:45:56 UTC
*** Bug 380171 has been marked as a duplicate of this bug. ***

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