Re: lots and lots of disks again

[Andrew Morton <akpm@osdl.org>]

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