On Thu, 2007-08-30 at 18:24 -0700, Andrew Morton wrote:
> On Thu, 30 Aug 2007 18:37:13 -0400 Trond Myklebust <[email protected]> wrote:
>
> > On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > > I am re-sending this after help from Ian and git-bisect. To me it's a
> > > show-stopper: I cannot find an acceptable workaround that I can implement.
> > >
> > > The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes several autofs
> > > mounts to fail silently - they just not appear when they should.
> > >
> > > I believe it's caused by the NFS change that forces multiple mounts from
> > > different directories under the same server side filesystem to have the same
> > > mount options by default, otherwise it returns EBUSY.
> > >
> > > For example, if server has a filesystem /a, and it exports /a/x and /a/y
> > > (maybe with rw or ro), and a client must mount /a/x and /a/y with the same
> > > mount options now.
> >
> > Which is better than having it fail silently, or giving you a mount with
> > the wrong mount options.
> >
> > If you need to mount the same filesystem with incompatible mount options
> > on the same client, then there is a new mount option "nosharecache",
> > which enables it.
> > The new option is there in order to make it damned clear to sysadmins
> > that this is a dangerous thing to do: mounts which don't share the same
> > superblock also don't share the same data and attribute caches. Any file
> > or directory which appears in both mounts had better only be used by one
> > application at a time or be using an appropriate locking scheme.
> >
>
> If we're going to send a message to sysadmins, we shouldn't force them to go
> through a git bisection search and a lkml discussion to receive it!
>
> Is there at least some way in which the kernel can detect this situation
> and emit a friendly printk which guides people to a friendly document?
There are already error codes being passed back to the mount syscall.
The problem here is that unlike the mount utility, autofs isn't passing
that information on to the user.
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
