From: "Paul Krizak" Subject: Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp Date: Mon, 14 May 2007 10:56:06 -0500 Message-ID: <46488696.9080009@amd.com> 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: nfs@lists.sourceforge.net, Ian Kent To: "Trond Myklebust" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1Hncug-00069J-Pk for nfs@lists.sourceforge.net; Mon, 14 May 2007 08:56:45 -0700 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Hncui-00073Q-9g for nfs@lists.sourceforge.net; Mon, 14 May 2007 08:56:45 -0700 In-Reply-To: <1179157631.6474.8.camel@heimdal.trondhjem.org> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net > 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. I can assure you that AMD systems engineering would *much* prefer having the VFS stack fixed such that we don't need to do something like this. It would be much better to make the kernel understand that it *can* mount the same NFS filesystem twice, once read-only and again read-write, with the appropriate cache coherency, rather than force us to run in a potentially dangerous configuration that might lead to data corruption. I agree with Ian that the VFS changes need to take priority. The only change I see that needs to be made to mount is that it needs to spit out a warning (or fail completely) if the requested options cannot be satisfied. Paul Krizak 5900 E. Ben White Blvd. MS 625 Advanced Micro Devices Austin, TX 78741 Linux/Unix Systems Engineering Phone: (512) 602-8775 Silicon Design Division Cell: (512) 791-0686 ------------------------------------------------------------------------- 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