Bug 250597

Yes, that should work and the last significant change
I made to autofs4 went into 2.6.21. I'll check for
differences but if it's outside of autofs4 then I'll
need to duplicate the problem on 2.6.22.

Unfortunately, the recent 2.6.22 kernel packages fail to
recognize my SATA disk so I can't even duplicate this
till I can get a revision of the kernel package that
will boot.

Could you get a debug log for the userspace daemon, at
least I'll have something to check in the mean time. Info
of that can be found on Jeff Moyers people page at http://people.redhat.com/jmoyer.

Ian

Created attachment 160536 [details]
debug log from automount

Here is a debug log I generated. This is with /home/hudson/misc mounted, then
/home/hudson/group attempting and failing to be mounted.

(In reply to comment #2)
> Created an attachment (id=160536) [edit]
> debug log from automount
> 
> Here is a debug log I generated. This is with /home/hudson/misc mounted, then
> /home/hudson/group attempting and failing to be mounted.

Thanks, I think I know what's causing this.
It's late here now so let me check tomorrow and perhaps
post to the kernel kernel list.

Ian

(In reply to comment #2)
> Created an attachment (id=160536) [edit]
> debug log from automount
> 
> Here is a debug log I generated. This is with /home/hudson/misc mounted, then
> /home/hudson/group attempting and failing to be mounted.

btw, would I be correct in saying that hudson:/vol/vol0/misc
and hudson:/vol/vol0/group are exports from within the same
filesystem and that this doesn't happen for exports of distinct
filesystems?

Ian

Yes, the nfs share is hudson:/vol/vol0

OK, I'm fairly sure the kernel patch linux-2.6-nfs-nosharecache.patch
causes this behavior.

The history is that at some time in the past superblock sharing
was added to the upstream kernel to avoid some nasty cache
coherency issues. This had the side effect of preventing second
and subsequent mounts from the same exported filesystem from
using different mount options, such as mixing rw and ro. There
was some unhappyness about this and the above patch was put
together to allow it to be over-ridden by a mount option
"nosharecache". Unfortunately, the patch returns -EBUSY when such
a mount is attempted and the new option is not specified, causing
the symptom you're seeing. No-one wanted to make "nosharecache"
the default because of the issues the original change resolved
which means an explicit "nosharcache" option is required.
Unfortunately, the current nfs-utils in Rawhide and F-7 doesn't
know about the option yet.

Ooops!
Ian

The nosharecache option will be in nfs-utils-1.1.0-3.fc7 which
will be in a yum repo near you... very soon... 

Yes, adding -Onosharecache to the OPTIONS line in /etc/sysconfig/autofs and
restarting autofs fixes the problem with this nfs version.

I was having same problems with 2.6.22.7-57.fc6 kernel. I added nosharecache
option and was able to mount the sub-directories, but now when I mount the
sub-directories it crashes rpcbind on my NFS server. We have Auspex NS3000 NFS
server.

I have nfs-utils-1.0.10-14.fc6 and nfs-utils-lib-1.0.8-7.2 installed on the system.

When rpcbind crashes the NFS access on Unix (AIX, HP-UX, various flavors of
Linux) slows down. I also share the NFS filesystem with PCs using samba and the
PCs cannot access the files. 

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I haven't had any problems since we rolled out the -Onosharecache option, so I
consider this fixed.