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 <[email protected]>
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
