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. ***