Re: lots and lots of disks again

Andrew Morton
2004-02-11T22:27:53Z

Kurt Garloff <garloff@suse.de> wrote:
>
> We're fighting about a static 4k array currently ;-)

yup. Sorry I was distracting.

> Actually, I'm not sure we currently have the right discussion here.

Absolutely.

I was rather hoping that Al would follow up on his comments yesterday
actually.

Kurt Garloff <garloff@suse.de> wrote:
>
> Hi Andrew,
>
> On Wed, Feb 11, 2004 at 01:28:48PM -0800, Andrew Morton wrote:
> > Kurt Garloff <garloff@suse.de> wrote:
> > > If we really allocate thousands of disks, the overhead of this solution
> > > will be higher than the bitmap, I'm afraid.
> >
> > Four (or eight) bytes per disk! I perceive a lack of perspecitve here ;)
>
> We're fighting about a static 4k array currently ;-)
>
> Well, it's certainly true that the memory we allocate in gendisk per
> disk is higher than these wasted 4/8 bytes. It's just that I don't like
> wasting anything ... The waste is 32/64times higher than with our
> bitfield, except that it's dynamic.
>
> > I'd trade clarity of implementation for that.
>
> You seem to have used idr often before. It took me much longer to read
> the docu and look at the function decsl than to understand the array
> and the meaning of find_first_zero_bit().
>
> > (As well as, possibly, reduced memory use on low-end machines).
>
> This one is true.
>
> If you think this is a relevant issue, tell me. I'll convert to use
> idr then. Currently, I'm not sure whether the patch has any chance
> to be merged, given the opposition of some people.
>
> Actually, I'm not sure we currently have the right discussion here.
>
> We want to have > 256 disk support, and we need to agree on how we
> want to present it to the user. Changing some implementation behind
> this is not really painful to do afterwards. Changing the way we
> interpret majors/minors would be painful. Thus the suggestion of
> Matthew which I liked and adopted. No need for new majors, no
> changes to the well known numbers.
>
> Of course there's the long term perspective of having a "disk" major
> and udev taking care of everything. This will happen, but nobody
> so far told that this should be done within 2.6. Nor do I see
> udev replacing the classical device nodes completely within that
> timeframe.
>
> If we want something useful now, we need to keep the old disks
> major/minor scheme untouched.
> I see two possibilities to get somes done:
> * Matthew's proposal (whatever we use the two extra "partition"
> bits for in the end)
> * Introducing new majors, where we introduce a new numbering scheme.
> One major can accomodate 65536 disks à 16 partitions or 8192 disks
> with 64 partitions. We'd allocate one new major and sort disks
> after 256 there. The 64 partitions is actually out of the race,
> as the number of possible partitions would depend on the order
> that scsi disks are detected :-/
>
> I think adding some bit shifting in the kernel is preferable to
> breaking user interfaces. The effort to fix all the apps is much
> higher. We should be aware that some bit shifting in the kernel
> is really not the most complex part of this picture.
>
> I would appreciate if those disliking Matthew's maj/min layout would
> come up with a proposal and tell what they want. Or maybe admit that
> they actually don't care?
>
> I'm definitely not religious about how to solve this. But I would
> like to have _a_ solution and I would like this solution not to
> change anything for already well-known devices.
>
> Once we have that, we can struggle about implememtation details that
> are easy to change anyways.
>
> Regards,
> --
> Kurt Garloff <garloff@suse.de> Cologne, DE
> SUSE LINUX AG, Nuernberg, DE SUSE Labs (Head)
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html