Naming and devlabel (was Re: [cgl_discussion] [Fwd: [ogfs-dev]EVMS
2.0 with cluster support])
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.
Peter Badovinatz wrote:
>John Cherry wrote:
>>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
>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.)
>>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
>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
More information about the cgl_discussion