lkml.org 
[lkml]   [2003]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] register_blkdev
This could easily be supported by removing the requirement that 16 
minors are used per disk. If instead, partition minors were dynamcially
allocated and created by userspace policies (or devfs), many thousands
of disks could be used in the current scheme (assuming they don't have a
bunch of partitions). I think it is unlikely anyone would actually use
more then one partition in a big disk setup, but I could be wrong. If
only one minor were used per disk, 10k disks could easily be supported
by the current dev_t.

Of course, the way block devices that represent disks register with the
system would have to change, but the current waste of minors by devices
that never exist is rediculous anyway.

Thanks
-steve

Joel Becker wrote:

>On Sat, Mar 08, 2003 at 07:43:31PM +0000, Christoph Hellwig wrote:
>
>
>>So people should have started working on it sooner. If people really think
>>they need a 32bit dev_t for their $BIGNUM of disks (and I still don't buy
>>that argument) we should just introduce it and use it only for block devices
>>(which already are fixed up for this) and stay with the old 8+8 split for
>>character devices. Note that Linux is about doing stuff right, not fast.
>>
>>
>
> Wait, so ugly hacks that steal every remaining major is doing it
>'right'? I've done the math with the current available majors. I don't
>see 4000 disks there, and that is just life as it exists today, not 2-3
>years from now when 2.8 finally appears. Like Andrew asked, please
>describe exactly how you'd support it.
>
>Joel
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.054 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site