From: Ian Kent <raven@themaw.net>
Subject: Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp
Date: Tue, 15 May 2007 00:06:52 +0800
Message-ID: <1179158812.3811.68.camel@raven.themaw.net>
References: <4627B3DD.5050409@amd.com>
	<1177007479.6623.14.camel@heimdal.trondhjem.org>
	<4627D303.8060009@amd.com>
	<1177020662.6628.30.camel@heimdal.trondhjem.org>
	<4627EBFC.2090704@amd.com>
	<462CFC92.2080201@amd.com> <463B97E6.4030009@amd.com>
	<1178314889.6533.19.camel@heimdal.trondhjem.org>
	<1178379473.4559.24.camel@raven.themaw.net>
	<1178385472.6561.43.camel@heimdal.trondhjem.org>
	<20070514131743.GG31764@petra.dvoda.cz>
	<1179149048.6858.5.camel@heimdal.trondhjem.org>
	<1179153555.3811.57.camel@raven.themaw.net>
	<1179157631.6474.8.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Paul Krizak <paul.krizak@amd.com>, nfs@lists.sourceforge.net
To: Trond Myklebust <Trond.Myklebust@netapp.com>
In-Reply-To: <1179157631.6474.8.camel@heimdal.trondhjem.org>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Mon, 2007-05-14 at 11:47 -0400, Trond Myklebust wrote:
> On Mon, 2007-05-14 at 22:39 +0800, Ian Kent wrote:
> > On Mon, 2007-05-14 at 09:24 -0400, Trond Myklebust wrote:
> > > On Mon, 2007-05-14 at 15:17 +0200, Karel Zak wrote:
> > > > On Sat, May 05, 2007 at 01:17:52PM -0400, Trond Myklebust wrote:
> > > > > On Sat, 2007-05-05 at 23:37 +0800, Ian Kent wrote:
> > > > > > On Fri, 2007-05-04 at 17:41 -0400, Trond Myklebust wrote:
> > > > > > So is there "anything at all" we can do to change this behavior now,
> > > > > > apart from teaching mount to about it. Having the /etc/mtab
> > > > > > and /proc/mounts recording different mount options for a mount is wrong.
> > > > > > 
> > > > > > How should mount(8) handle the situation?
> > > > > 
> > > > > I'd rather like to have mount(2) handle the situation by returning an
> > > > > error if the mount options cannot be satisfied.
> > > > 
> > > >  Agree, that makes sense. Unfortuantely this change is probably not
> > > >  backwardly compatible. Maybe add a new mount(2) flag MS_STRICT which
> > > >  disable a mount when the mount options cannot be satisfied.
> > > 
> > > The kernel would be sending the error to the mount program when it
> > > cannot satisfy the request. There is no backwards compatibilty issue.
> > 
> > I guess that depends on how you interpret backwardly compatible.
> > 
> > Deciding to now fail mounts in this case would turn an unfortunate side
> > effect of an urgently needed change into a disaster for some users. I
> > think it's best to leave it as it is and push on with the needed VFS
> > changes.
> 
> No. It would alert people who think they are mounting with different
> mount options to the reality that they are not.
> 
> We might then be able to add an '--unshared-cache' option (any
> suggestions for a better name?) to mount in order to allow those people
> who fully understand the consequences to override, and hence to mount
> the same filesystem with different mount options, but no sharing of the
> page cache with the original filesystem.

Not sure, perhaps "--force-options" or "--force-samefs-options".

I've heard back from Dave Hansen and he is planning on posting the VFS
patches in the relatively near future. As you said, it would be best to
resolve this in the VFS so I'm not sure how much effort should be put
into this here.

>From what I can see Dave has put quite a bit of effort into his patches
already so they should be close to ready for submission. Hopefully they
are what's needed.

Ian


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs