Re: recent nfs change causes autofs regression

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 4 Sep 2007, David Howells wrote:
> 
> That helps one case, yes, but what about a superset?  What about two sets that
> might intersect but for which you don't have the common root to hand?

Sure. In which case bind mounts don't work. Fair enough.

> The case I came up with was this:
> 
> 	mount home:/home/fred /home/fred
> 	mount home:/home/jim /home/jim

The much more trivial case is

	mount -o ro server:/usr/bin /usr/share/bin
	mount server:/usr/tmp /usr/share/tmp

and now tell me any reasonable reason why this should fail? (Replace "-o 
ro" with any other attributes).

Quite frankly, if the above two mounts fail - just beause /usr/bin and 
/usr/tmp happen to be on the same filesystem on the server - then the 
implementation is more than just buggy - it's a pure piece of shit.

And quite frankly, as far as I can tell, that was exactly what the NFS 
changes that are being discussed did. They failed the equivalent of the 
second mount, because it didn't have the same flags as the first one.

Can you really honestly say that wasn't totally broken?

> The reason I added all this NFS superblock sharing is so that I could implement
> on-disk local caching much more easily.  If, for instance, two netfs inodes
> aren't shared, but their "index keys" say they should use the same piece of
> cache then all sorts of fun ensues from the disjoint cache coherency.
> 
> Even working out that two inodes are using the same piece of cache isn't
> trivial (though it seems like it ought to be).

I'm just saying that the whole "require all mount flags to be identical, 
and error out if they are not" is pure and utter CRAP.

So anything that does that - for *any* reason what-so-ever - is just 
broken. If you require identical mount-time flags, that absolutely has to 
be a special case (like using "--bind", or perhaps using a special option 
like "sharecache").

It really is that simple. I don't know how anybody could possibly ever 
dispute that.

As far as I can tell, the current situation in NFS is "reasonably ok", but 
I already asked Trond about what happens with "remount" with the "same 
mount options imply sharecache" code that he did, and afaik, I never got 
an answer. In other words, let's change the above two commands to the 
following three commands:

	mount server:/usr/bin /usr/share/bin
	mount server:/usr/tmp /usr/share/tmp
	mount -o remount,ro /usr/share/bin

and I'm claiming that if the above fails (or remounts /usr/share/tmp as 
read-only too), then it's also obvious CRAP (replace "ro" with any other 
possible attribute - whether cache timeouts or similar)

See? It really is that simple. The obvious mount usage above absolutely 
*has* to work, and anything that breaks it is crap, crap, crap. And that 
was exactly what apparently happened here, and I really don't see why 
anybody has the *gall* to claim that the "default to sharecache" code 
wasn't totally broken.

			Linus
-
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/