New storage code and cciss

[Hans de Goede <hdegoede redhat com>]

Hi All,

Today I've been looking in to how cciss and the new storage code
(theoretically) interact. Poking around on a cciss equiped
rhts system (with rhel-5 on it, which is showing its age).

So the story with cciss is:
It has sysfs entries like this:
/sys/class/block/cciss!c0d0

Where udev translates the ! to a /, leading to device nodes
like this:
/dev/cciss/c0d0

Basically udev will always translate an ! in a device name
to / before creating device nodes.

Partitioning is pretty normal, other then that it is living
under a subdir. But I've already tackled that in a generic
manner when adding support for dmraid partitions.

udev does use the untranslated name for the db file, so that
is:
/dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:1b.0......\x2fcciss!c0d0

And the N: entry in their (which results in our Device name attribute)
has the translation so that ends up as: cciss/c0d0

Since Device.name contains the /, things like Device.path will actually
do the right thing.

So things sort of work, except that we've got code in various places which
expects that Device.path.split("/")[-1] will get the device name, and
Device.updateSysfsPath() will mess things up (as it will not translate
the / to a !.

Given that things almost work, and we are likely to encounter more cases
like this, my proposal to fix this is to make the generic DiskDevice and
PartitionDevice classed handle this correct. I don't think that having an
cciss-disk class and then also a cciss-partition class is a good idea. Esp
having multiple partition classes has turned out to be a bad idea as dmraid
has shown.

Moving forward There are 2 ways to fix things:
1) Strip away the part before the / in the name we get from udev,
   so that means instead of putting cciss/c0d0 in the name put in just
   c0d0

   Advantages:
   -code which assumes that Device.path.split("/")[-1] == Device.name
    stays working

   Disadvantages:
   -needs special _devpath handling
   -needs *very* special updateSysfsPath handling, where we need
    to come up with the prefix again
   -may lead to non unique names esp with i2o, which if I've googled
    correctly has i2o/hda, which will collide with plain hda on
    for example ppc if we remove the prefixed dir from the name

2) Keep the name as seen / given by udev as is, so cciss/c0d0

   Advantages:
   -has non of the disadvantages of option 1.
   -not doing anything to the name requires no code

   Disadvantages:
   -we need to fix the code which assumes that
    Device.path.split("/")[-1] == Device.name
    (one could actually call this an advantage)
   -still need some special handling in updateSysfsPath
    (replace / with !)

Option 2 gets my vote (it always helps to type mails like this,
then at the end you sort of have the answer to what you were to ask).

Regards,

Hans