Messages in this thread | | | Date | Sat, 01 Sep 2007 20:58:25 -0400 | From | Bill Davidsen <> | Subject | Re: recent nfs change causes autofs regression |
| |
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@tmr.com> "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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |