Naming and devlabel (was Re: [cgl_discussion] [Fwd: [ogfs-dev]EVMS 2.0 with cluster support])

Steven Dake sdake at mvista.com
Thu Apr 3 15:29:23 PST 2003


devlabel is a decent solution and so is scsidev (similiar in nature).

The downside of these solutions is there is no backing store database, 
and hence no way to associate certain kinds of information with a 
physical device.  For example, it would be useful to be able to 
associate a slot, chassis ga, and position within the slot of a specific 
disk.  For the multipathing configuration, it would be useful for 
whatever tool manages device names to automatically create the correct 
device nodes based upon the physical layout of the devices that map to 
the multipaths.  There are other limitations, such as when the unique 
identifier of the device changes and in the case of scsidev, when the 
port of the scsi device changes.  Also, consider how permissions are 
managed on devices that can change.  These tools don't attempt to solve 
the permission problem and ensuring that changes in permission are kept 
through hotswap and reboot operations.

For all of these reasons, a more focused approach to solve this problem 
should be applied that attempts to meet the real requirements of 
customers interested in disk hotswap and device naming (and not just 
scsi devices) issues.  In linux kernel 2.5 this can easily be done using 
sysfs and policies that execute device naming based upon data from 
sysfs.  A clever solution would be able to use the backing store 
database and sysfs to also create other kinds of device configurations, 
such as storing RAID configurations for raid starting and multipath 
configurations for starting multipaths.

Thanks
-steve

Peter Badovinatz wrote:

>John Cherry wrote:
>  
>
>>Pai,
>>
>>Thanks for the clarification on naming.  I was not implying that EVMS
>>was going to address the consistent naming in a cluster at the device
>>level.  However, if all "shared" devices are encapsulated in shared
>>containers, then we have consistent volume names in the cluster.
>>    
>>
>
>Does anyone have experience with 'devlabel', apparently done by folks at
>Dell?
>http://www.dell.com/us/en/esg/topics/power_ps1q03-lerhaupt.htm
>http://www.lerhaupt.com/linux.html
>
>A RH Linux 9 review (http://www.gurulabs.com/RedHatLinux9-review.html)
>lists devlabel as being included, to deal with the issue:
>"There has been a longstanding issue in Linux in that in the face of OS
>changes or hardware failures, storage devices can "move" to different
>locations. For example, although IDE devices have their physical path
>hardcoded into their device name, eg /dev/hdc3, SCSI devices are not."
>
>I ask because I've never heard of it, but it seems to address some of
>our concerns.  I haven't read all of the material, I don't know if it's
>tightly tied to Oracle support (although it does help support Oracle.)
>
>  
>
>>John
>>
>>On Wed, 2003-04-02 at 15:22, Ram Pai wrote:
>>    
>>
>>>On Wed, 2 Apr 2003, Peter Badovinatz wrote:
>>>
>>>      
>>>
>>>>John Cherry wrote:
>>>>        
>>>>
>>>>>EVMS has been released as a clustered volume manager.  It could address
>>>>>things like cluster wide device naming and could replace the notion of
>>>>>pools in OpenGFS.  Does anybody on the cgl_discussion list have some
>>>>>bandwidth to evaluate this?
>>>>>          
>>>>>
>>>We support cluster wide **volume** device naming. What this means is
>>>that EVMS volumes created on Shared containers will show up as a
>>>volume device with the same name on all cluster nodes.
>>>
>>>And from the discussion with the OpenGFS folks today, I understand
>>>that this is what they want.
>>>
>>>Pools can be replaced with EVMS volume devices residing on shared container.
>>>However we do not have an equivalent of a sub-pool.
>>>
>>>We are eager to receive feedback, and requirements that drives our future
>>>development.
>>>
>>>Thanks,
>>>      
>>>
>
>Peter
>--
>Peter R. Badovinatz aka 'Wombat' -- IBM Linux Technology Center
>preferred: tabmowzo at us.ibm.com / alternate: wombat at us.ibm.com
>These are my opinions and absolutely not official opinions of IBM, Corp.
>_______________________________________________
>cgl_discussion mailing list
>cgl_discussion at lists.osdl.org
>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>
>
>
>  
>




More information about the cgl_discussion mailing list