Re: New model for managing dev_t's for partitionable block devices

Re: New model for managing dev_t's for partitionable block devices

[Andrey Borzenkov]

> This is a problem with hotswap of course, and shouldn't be solved
> by the kernel putting the same device always in the same
> major/minor.  A userspace application should query the OS and build
> the device nodes based upon scsi serial number, FC port WWN, or
> access path (host/channel/id/lun).  The current "MAKEDEV" works
> fine for people with and ide disk and cdrom, but for real systems
> with lots of disks and hotswap capabilities, static naming just
> doesn't work (as you have said).  :)  Devfs solves the naming
> problem by using access path automatically within the OS.  Downside
> of this methodology is that access permissions are not persistent
> between reboots (which is one significant limitation of devfs).


Are you aware of devfsd? It keeps permissions for you across reboots,
and does it just fine.

The real limitation in this case is SCSI host numbers. There is no
way to permanently assign logical controller numbers like it happens
in other systems. add or remove another SCSI adapter and all your
names are shifted.

which is true for any adapter not just SCSI.

-andrey

Re: New model for managing dev_t's for partitionable block devices

[Alex Tomas]

>>>>> Andrey Borzenkov (AB) writes:


 AB> Are you aware of devfsd? It keeps permissions for you across
 AB> reboots, and does it just fine.

 AB> The real limitation in this case is SCSI host numbers. There is
 AB> no way to permanently assign logical controller numbers like it
 AB> happens in other systems. add or remove another SCSI adapter and
 AB> all your names are shifted.

 AB> which is true for any adapter not just SCSI.

one may use Inquiry/EVDP information from SCSI device

Re: New model for managing dev_t's for partitionable block devices

[Steven Dake]

Horst von Brand wrote:

>Steven Dake <sdake@mvista.com> said:
>  
>
>>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.
>>    
>>
>
>Great idea! Add another partition, and the minors for everything else on
>the system change. Not!
>
It isn't minors that shouldn't change, it is the mapping of the 
filesystem device node to those minors.  This can be achieved by 
properly managing device naming in userspace automatically on partition 
updates, instead of using static naming such as /dev/sda which already 
has significant problems when devices are removed/inserted in hotswap 
environments.

The fact that minors change is irrelevant if proper steps are taken to 
ensure that those minors always map to the correct named device in user 
space.

Thanks
-steve

>  
>

Re: New model for managing dev_t's for partitionable block devices

[Horst von Brand]

Steven Dake <sdake@mvista.com> said:
> 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.

Great idea! Add another partition, and the minors for everything else on
the system change. Not!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: New model for managing dev_t's for partitionable block devices

[Steven Dake]

For newer revs of linux, I was specifically thinking of implementing 
using device mapper to provide partition mapping so your thinking just 
like me :)  The only downside is device mapper becomes a required 
component instead of being module capable since partition information is 
needed before early boot is available to load modules.

Regards,
-steve

Valdis.Kletnieks@vt.edu wrote:

>On Tue, 28 Jan 2003 10:20:31 MST, Steven Dake <sdake@mvista.com>  said:
>
>  
>
>>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.
>>    
>>
>
>This sounds suspiciously like the already-existing device mapper stuff
>used by LVM2.  Maybe all that's needed is to add a hook to add a device
>mapper entry for each partition?
>  
>

Re: New model for managing dev_t's for partitionable block devices

[Valdis.Kletnieks]

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

On Tue, 28 Jan 2003 10:20:31 MST, Steven Dake <sdake@mvista.com>  said:

> 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.

This sounds suspiciously like the already-existing device mapper stuff
used by LVM2.  Maybe all that's needed is to add a hook to add a device
mapper entry for each partition?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


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

New model for managing dev_t's for partitionable block devices

[Steven Dake]

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

>