On Sat, 12 Aug 2000, Linus Torvalds wrote:
> > need to lift the 255-anon-mounts limit.
>
> [ Thinking about it ]
>
> I don't think you necessarily need to fix even that.
Just a quick check: we are still talking about 2.5, aren't we?
> I'm not positive that you even need a new "struct super_block". You could
> use the same superblock, and just move some more information into the
> vfsmount. Which _is_ easy to allocate, and doesn't have any of the
> anon-mount list issues that the superblock has.
Umm... struct super_block is obese, indeed, but that can be helped.
> Besides, you _do_ want to have some good way to reach the underlying
> superblock anyway, even from such a "sub-mount". Just sharing the sb
> directly would be one easy way.
>
> (No, I haven't checked all the details. There may be overriding reasons
> why you'd not want to re-use the same superblock. And there may be tons of
> small details too).
Well, for one thing you definitely want different super_operations. Sure,
we can roll such checks into every method ("is it a real thing or just a
submount"), but that's just plain ugly. Another thing being, games with
->s_root will become painful.
Again, I really think that lifting that limit is a good thing for many
other reasons and if we are talking about 2.5 - I'll do that. If you want
forks in 2.4.0... professional help may be in order.
As for lifting this limit - about the only place (in kernel) that really
cares is the icache. That's _very_ easy to deal with - just cache by
struct super_block * instead of kdev_t. _That_ can be done right now (I
can submit you such patch tonight if you want it) and IMO it makes sense
regardless of the limit.
Other place that cares is stat(), but that can be dealt with when we will
actually start playing with that limit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST