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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
