Hi,
On 12/01/2009 09:15 PM, Chris Lumens wrote:
Unfortunately, the udev data for CCISS does not contain MD_* so I can't use
the udev_device_is_md to key off. This will have to do.
---
storage/udev.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/storage/udev.py b/storage/udev.py
index ee750bb..6351b22 100644
--- a/storage/udev.py
+++ b/storage/udev.py
@@ -168,6 +168,10 @@ def udev_device_is_md(info):
return info.has_key("MD_DEVNAME") and \
info.has_key("MD_METADATA")
+def udev_device_is_cciss(info):
+ """ Return True if the device is a CCISS device. """
+ return udev_device_get_name(info).startswith("cciss")
+
def udev_device_is_dasd(info):
""" Return True if the device is a dasd device. """
devname = info.get("DEVNAME")
A cciss raid device is a hardware raid device, so for all purposes
inside anaconda the cciss virtual drives are just disks. Unlike with
software raid we never get to see the real disks hiding behind the
raid controller in anyway. So it is quite normal there are no MD_
attributes as this is not software raid. As such I don't think we
should treat the cciss attached disks (as we see them, so the virtual
disks / raid sets) special in anyway.
There are a lot of other hardware raid solutions, and I don't think we
should start building a list of devicename prefixes to identify them.
Esp as undoubtedly some will just show up as regular scsi disks (sdX),
so trying to identify hardware raid controlled virtual disks / sets and
marking them in the UI as such will lead to a maintenance problem as
each time a new sort of hardware controller pops up we will need to
add code to detect the disks we are finding are not really disks but
hardware controlled raid sets.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
