lkml.org 
[lkml]   [2003]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectNew model for managing dev_t's for partitionable block devices
I was thinking of an entirely new model for partitionable block devices. 
Here is how it would work:

Each physical disk would be assigned a minor number in a group of
majors. So assume a major was chosen of 150, 151, 152, 153, there would
be a total of 1024 physical disks that could be mapped. Then the device
mapper code could be used to provide partition devices in another
major/group of majors.

The advantage of this technique is that instead of wasting tons of
minors on partitions that are never used, partitions could be
dynamically allocated out of the minor list, allowing for thousands of
disks with varying numbers of partitions each. Further instead of each
block device (such as i2o, scsi, etc) having their own set of majors for
each partitionable disk (which wastes dev_t address space) everything
would be compressed into the same set of majors.

As an example, Lets assume we want 4096 total disks with 16384 total
partitions (4 partitions per disk, where it is likely to be less):

That is:
4096 disks / 256 disks * 1 major = 16 majors
16384 partitions / 256 partitions * 1 major = 64 majors
total of 80 majors

To allow a similiar configuration in the current block device setup,
with just the SCSI disk major,
4096 disks / 16 disks * 1 major = 256 majors

Now, assume we have 4096 disks available for i2o, scsi, compaq raid, etc
etc, we are talking about lots of majors that go way beyond the current
addressable 16 bytes.

The only downside is addressing the disks in hotswap (ie: how do you
know what disk is where?) This can be achieved through per-subsystem
devfs mapping (ie: linking /dev/scsi/hostX/... to /dev/disc0) or
userspace utilities that scan the disk devices (such as those that would
be in /dev/disk) and determine which disks are what.

Thanks
-steve

>

-
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:32    [W:0.070 / U:2.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site