![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2007-09-02 01:01 [from the cache] ©2003-2008 | |||||||||||||