RE: recent nfs change causes autofs regression

["Hua Zhong" <hzhong@gmail.com>]

> On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> > >
> > > Which is better than having it fail silently, or giving you a mount
> > > with the wrong mount options.
> >
> > Well, it depends on how you define "better".
> 
> "better" as in: "I now have a chance to notice, when my 'read-only
> mount' is actually 'read-write'".
> 
> > In this particular scenario, the maps read as follows:
> >
> > tools
> > -
> fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n
> fsve
> > rs=3,actimeo=600 fs1.domain.com:/a/tools
> > share
> > -
> fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n
> fsve
> > rs=3 fs1.domain.com:/a/share
> >
> > The only difference is in the actimeo (I don't even know what it
> > means). Is this enough to fail a mount?
> 
> Yes. The default values for acregmin, acregmax, acdirmin, acdirmax are
> not 600. If /a/tools and /a/share are on the same filesystem on the
> server, then the NFS client should warn you that you are about to do
> something that may result in cache coherency problems instead of
> silently allowing it, and then leaving you to debug the coherency issue.

There are two disjoint directories. I am wondering why there would be cache
coherency issues in this case? Is this Linus nfs implementation specific or
all other Unix systems all have the same issue?

> If you know what you are doing, then there is an option which allows
> you to override the default behaviour.
> 
> > More importantly, it is a regression. My understanding is that unless
> > absolutely necessary we do not introduce a "feature" that breaks
> > working setups.
> 
> Your turn to define what you mean by "working"? In my book that means
> "a setup that doesn't include unexpected or unintended behaviour".

"working" as in "I can mount the directory and do my work". And there has
never been any problems as far as I know.

> Not being able to notice cache coherency failures on a file that is
> mounted in two different places with two different sets of mount
> options counts as "unexpected behaviour".
> 
> Not being able to notice that your mount options have been overridden
> by the kernel also counts as "unexpected behaviour".

Fine. These are all very nice theories, but I just want to report this
regression and hope it won't cause any big problems for any users out there.
In the mean time, I am returning to 2.6.22.

> Trond