Re: recent nfs change causes autofs regression

From: Bill Davidsen
Date: Sat Sep 01 2007 - 20:58:41 EST


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/