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
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 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
(an earlier NFSALL), I don't believe the server makes a difference
on the issue of the client not seeming to recogonize the sync
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
behavior? And should something give a warning since one user
specified options overrides another user specified option in a
very nonobvious way?

The write performance stinks rather badly with the sync option
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
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 - ***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[Trond Myklebust]

Post by Heflin, Roger A.
mount -t nfs -o rw,hard,lock,intr,noac,async
hoepld31:/ptmp/hoepld31 /tmpmnt/ptmp/hoepld31
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 - ***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[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.
solaris noac has always behaved this way, and Linux noac
has behaved like this since around 2.4.7.

We don't expect to get the writes another client does
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
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
documented a little better.

Post by Heflin, Roger A.
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
behavior? And should something give a warning since one user
specified options overrides another user specified option in a
very nonobvious way?

noac is a synonym for "actimeo=0,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.

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.

Post by Heflin, Roger A.
The write performance stinks rather badly with the sync option
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.

synchronous writes are always slow.
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.

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.

Post by Heflin, Roger A.
SYNC is specified on the exports line on the remote server,
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
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).

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.

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.

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 - ***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[Heflin, Roger A.]

This post might be inappropriate. Click to display it.