Re: lots and lots of disks again

[Kurt Garloff <garloff@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]