NFS mount option - noac forces sync even if async is specified, and no warning is given

NFS mount option - noac forces sync even if async is specified, and no warning is given

[Heflin, Roger A.]

I run the following command:

mount -t nfs -o rw,hard,lock,intr,noac,async=20
     hoepld31:/ptmp/hoepld31 /tmpmnt/ptmp/hoepld31

And then cat /proc/mounts:

hoepld31:/ptmp/hoepld31 /tmpmnt/ptmp/hoepld31 nfs =
rw,sync,v3,rsize=3D8192,
     =
wsize=3D8192,acregmin=3D0,acregmax=3D0,acdirmin=3D0,acdirmax=3D0,hard,int=
r,
     udp,noac,lock,addr=3Dhoepld31 0 0

Note that async is specified on the mount line and /proc/mounts
specifies that sync was used.  If I don't use the async option the same
thing happens.  This is with 2.4.21pre3 NFSALL and utils-1.0.1-1 (as
included by RH7.3)  for the client.  The server is 2.4.19 NFSALL=20
(an earlier NFSALL), I don't believe the server makes a difference
on the issue of the client not seeming to recogonize the sync=20
option.   The client and server are both originally based on RH7.3.

If I remove the noac option, then the async option seems to be
honered, but not with the noac option on the line, is this the =
documented=20
behavior?  And should something give a warning since one user
specified options overrides another user specified option in a=20
very nonobvious way?

The write performance stinks rather badly with the sync option=20
enabled, and I could see why you *might* want to force it with
noac, but not if the user is attempting to override the sync option
with async.

SYNC is specified on the exports line on the remote server, and my
understanding was that you want sync on the exports line, and=20
async on the mount line on the client, but I cannot seem to get it
to take async on the mount line (no error is given, but it appears
to have been ignored, trying a known bad option -say nosync does
give a error saying bad option).

				Roger




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: NFS mount option - noac forces sync even if async is specified, and no warning is given

[Trond Myklebust]

>>>>> " " == Roger A Heflin <Heflin> writes:

     > I run the following command:

     > mount -t nfs -o rw,hard,lock,intr,noac,async
     >      hoepld31:/ptmp/hoepld31 /tmpmnt/ptmp/hoepld31

     > And then cat /proc/mounts:

     > hoepld31:/ptmp/hoepld31 /tmpmnt/ptmp/hoepld31 nfs
     > rw,sync,v3,rsize=8192,
     >      wsize=8192,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,intr,
     >      udp,noac,lock,addr=hoepld31 0 0

     > Note that async is specified on the mount line and /proc/mounts
     > specifies that sync was used.  If I don't use the async option

That's right. 'noac' enforces 'sync' in order to remain compatible
with the expected behaviour of noac on other NFS client
implementations.

If you don't need 'sync', you can specify

   acregmin=0,acregmax=0,acdirmin=0,acdirmax=0

instead.

Cheers,
  Trond


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: NFS mount option - noac forces sync even if async is specified, and no warning is given

[Heflin, Roger A.]

> noac without sync writes doesn't make much sense, does it?
> noac is used to cause multiple clients to share files pretty
> tightly.  even if client A is aggressively checking a server
> for changes to a file, it will not detect changes unless
> all the other clients send their writes as submitted by the
> app, rather than delaying them.
>=20
> solaris noac has always behaved this way, and Linux noac
> has behaved like this since around 2.4.7.
>=20
	We don't expect to get the writes another client does=20
	immediately, we want to see the file creates/attribute changes
	close to real time, not the data itself, the applications have
	a way of dealing with the data not being in sync, and don't
	even expect it to be consistant over the short term.

	I think the problem is with the name, noac which is explained
	as no attribute caching, and on Suns it is explained as no
	data and attribute caching (I just checkd the man) not exactly
	a consistant naming on Sun's part.  It should probably be=20
	called nocache since that appears to be what it is doing.
	Changing linux to be more consistant with Sun, but less
	consistant with previous version of linux nfs should at least be=20
	documented a little better.


> > If I remove the noac option, then the async option seems to=20
> > be honered, but not with the noac option on the line, is this=20
> > the documented=20
> > behavior?  And should something give a warning since one user=20
> > specified options overrides another user specified option in a=20
> > very nonobvious way?
>=20
> noac is a synonym for "actimeo=3D0,sync" which is the behavior
> of least surprise in this case.  if you look at the Solaris
> man page which describes noac, you will see that Solaris's noac
> behaves this way.  maybe the Linux mount_nfs man page hasn't
> been updated to reflect this behavior.
>=20
	It is only the behavior of least suprise if you are using Solaris
	as the reference, not if you are using previous version of linux
	as the reference.

	None of the man pages document the behavior, and  mount
	should return a warning (at least) that the two options (noac,async)
	don't agree with each other.

> > The write performance stinks rather badly with the sync option=20
> > enabled, and I could see why you *might* want to force it=20
> > with noac, but not if the user is attempting to override the=20
> > sync option with async.
>=20
> synchronous writes are always slow.
>=20
> perhaps the real bug is that noac,async doesn't work the way
> you expect it.  i can think of only one instance where this
> might be desired: if the writing application resides on the
> file server.
>=20
	The real bug it there is no documentation on any of the recent
	changes, the man pages are completly useless, and horribly
	out of date.    Attribute caching was previously described as
	attributes, and then changed to be the same as
	Sun's definition of all caching, somewhat of a major change,
	with no documentation changes.  None of the man pages say
	anything aboue disabling *ALL* caching, and putting the client
	into sync mode.  And mount does not scream about
	noac and async being non-compatible.

> > SYNC is specified on the exports line on the remote server,=20
> > and my understanding was that you want sync on the exports line, and =

> > async on the mount line on the client, but I cannot seem to=20
> > get it to take async on the mount line (no error is given,=20
> > but it appears to have been ignored, trying a known bad=20
> > option -say nosync does give a error saying bad option).
>=20
> sync on the server side is not the same as sync on the client
> side.  take a look at the NFS FAQ or review the archives of
> this list to see why this is the case.
>=20
	I know all about this, I got burned by those options when the
	sync behavior was changed from the original probably incorrect
	definition of only sync on certain things (attributes and such)
	 to sync on all writes.  =20

	It would be very helpful if these major changes in how previous
	version worked were documented someplace, or at least put
	in the HOWTO or FAQ's.

					Roger


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: NFS mount option - noac forces sync even if async is specified, and no warning is given

[Heflin, Roger A.]

> .
>=20
> then trond's suggestion of reducing the attribute cache timeout
> values to zero is your answer for now.
>=20
	I have now put that into place.    We rely on the file creations
	and size changes to be seen immediately but cannot afford
	the performance hit to allow the writes to be sync, so we live
	with the application needing to be aware of this issue.  The =
application
	actually rsh's to the disk node and touchs the file to update
	its time so that the cache will be tossed on the remote nodes=20
	for a new open. Over the several seconds that we need things to=20
	be consistant this works fine.

> ah, but Solaris noac doesn't disable *data* caching.  data is still
> cached until the client detects the file has changed.  *writes* are
> no longer cached, but reads can hit the client's data cache as long
> as the file doesn't change on the server.
>=20
	Then their manpage is also wrong.  On 2.6 (and 2.8) it says:
	         noac           Suppress data and attribute caching.

	It sounds very much like they kill all caching, but who knows
	what they actually do.


> besides, when was the last time you found that documentation matched
> implementation 100% on any operating system?
>=20
	Not as of yet, though some are close than others.  At least with
	linux I can get an answer in a reasonable time frame.

> >     And mount does not scream about
> > 	noac and async being non-compatible.
>=20
> arguable.  there are plenty of combinations of mount options that are
> inadvisable or ineffective.  here's a good one:
>=20
>   mount -o soft,udp,rsize=3D1024,wsize=3D1024,timeo=3D2
>=20
> another good one:
>=20
>   mount -o tcp,timeo=3D1
>=20
> here's an interesting case that neither works nor complains:
>=20
>   mount -t nfs -o tcp
>   mount -t nfs -o udp,remount
>=20
> or how about this, which isn't dangerous, but has no effect:
>=20
>   mount -t nfs -o noatime
>=20
> is mount supposed to know about all combinations for all file systems,
> and make sure you never make a mistake?  perhaps better checking can
> and should be added to the NFS client over time.  and maybe even the
> combination of "noac,async" should be made to work as you expect.
>=20
	I would agree lots of those are inadvisable, but at least it does=20
	in the proper unix way do exactly what you told it to, noac,async
	does not, it ignores the explicit option, ignoring an explicit option
	and shooting someone in the foot is rather worse, than letting you=20
	shot yourself because you pointed at your foot and pulled the
	trigger things to.

	I almost think Sun did the noac option the way they did because
	the did not have the sync/async option to use, so they rolled
	too many things into one.   And you are correct probably initially
	it was noac and then later became noac,syncwrites.

	I wish I still had a SunOS 4 machine to check and see
	how it worked on there.

	                            Roger


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs