Re: recent nfs change causes autofs regression

[Bill Davidsen]

Trond Myklebust wrote:
> On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
> > Please send in a fix. If the fix involves making "nosharecache" the 
> > default, then that is better than making policy decisions like this in the 
> > kernel. The kernel should do what the user asks and not put in unnecessary 
> > roadblocks.
>
> The best I can do given the constraints appears to be to have the kernel
> first look for a superblock that matches both the fsid and the
> user-specified mount options, and then spawn off a new superblock if
> that search fails. The attached patch does just that.
I'm glad I read the whole thread, because when I saw it earlier and 
didn't respond, this was the question I had, why not replace the error 
with forcing "nosharecache" on, which is essentially what you have done.

> Note that this is not the same as specifying nosharecache everywhere
> since nosharecache will never attempt to match an existing superblock.
>
> Finally, for the record: I still feel very uncomfortable about not being
> able to report the state of the client setup back to the sysadmin.
> AFAIK, the only way to do so is to stat the mountpoints, and compare the
> device ids.
Since clients may not know the server setup, and it may change for 
policy or error recovery reason, I think this patch is needed.

The cases I think are common are:

1 - single export, multiple client mounts

export /base - rw

mount /base/share - ro		[ client enforces r/o or not ]
mount /base/upload - rw

2 - export parts of a filesystem (/base) [ server enforces access ]

export /base/share - ro		[ hopefully really r/o on client ]
export /base/upload - rw	[ should work for write ]

3 - mount the same f/s with different permissions on client

export /base - rw

mount /base on point1 - rw	[ hopefully really r/w ]
mount /base on point2 - ro	[ hopefully r/o ]

I consider this *really* bad practice, but I have seen it in enough 
places to know others don't agree. It assumes the client will protect 
the r/o data.

4 - export f/s and part of f/s

export /base/ - ro
export /base/upload - rw

clients may mount one or both, with the upload directory as part of base 
or elsewhere. What will happen here?

> Trond


--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/