From: "Lever, Charles" <Charles.Lever@netapp.com>
Subject: RE: NFS suport block sharing
Date: Wed, 18 Feb 2004 18:27:48 -0800
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <482A3FA0050D21419C269D13989C611302B07B87@lavender-fe.eng.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Cc: <nfs@lists.sourceforge.net>, "Olaf Kirch" <okir@suse.de>
To: <trond.myklebust@fys.uio.no>
Errors-To: nfs-admin@lists.sourceforge.net

> We should aim only to have 1 super block per filesystem. Anything else
> will lead to inode aliasing, and hence potential data=20
> corruption problems
> when two processes try to write to the same file on different super
> blocks.
>=20
> Is there really any sane application that requires you to=20
> have different
> rsize/wsize for the same filesystem?

an application suite may want to mount one file system with
forcedirectio (if such an option might exist), and another
normally.  with the shared super block scheme, this is no
longer possible.

another typical use for having two unshared cached copies of
a file is to test NFS client caching (and yes, we do this
all the time).

so there are some "sane" cases i can think of where separate
caches and/or mount options for the same export make some
sense.

if nothing else, /proc/mounts and /etc/mtab should reflect
the true mount options in effect, and there should be some
explanation of this bizarre phenomenon in the man page.  the
way it works now is totally confusing.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs