crash utility dminfo extension hacking

I had done this a long time ago while triage of multipath based core dumps were a regular occurrence for me. Some of the extra plugins for crash are way out of date and require access to private data structures to reconstitute the view of the subsystem. Here's an example of porting the dminfo plugin for use with Linux 2.6.32.

https://code.launchpad.net/~peter-petrakis/ubuntu/oneiric/crash/dminfo-update

and the diffs

What I would like to do someday is figure out how to "mount" sysfs from crash context and use the device model to obtain these data structures in a deterministic manner. That would make these sort of plugins much more robust.

Determine Linux "sd" names for debugging

The way the Linux SD driver works is it reserves 16 minor 'slots' per block device, the first minor represents the whole disk, and the remaining 15 are reserved for partitions. Knowing this offset one can write a little python code to create an index table that aids debugging, mapping minor numbers back to block device names. This of course presumes that names are being recycled.

# python -c "print zip(range(0,443,16), map(chr, range(97, 123)))" [(0, 'a'), (16, 'b'), (32, 'c'), (48, 'd'), (64, 'e'), (80, 'f'), (96, 'g'), (112, 'h'), (128, 'i'), (144, 'j'), (160, 'k'), (176, 'l'), (192, 'm'), (208, 'n'), (224, 'o'), (240, 'p'), (256, 'q'), (272, 'r'), (288, 's'), (304, 't'), (320, 'u'), (336, 'v'), (352, 'w'), (368, 'x'), (384, 'y'), (400, 'z')]

So sdb would be 8,16 and sdm would be 8,192, sdm1 is 8,193. Now the next time you see something awful like this:

Jul 10 15:08:25 | checker failed path 8:144 in map mpath2 Jul 10 15:08:25 | libdevmapper: ioctl/libdm-iface.c(1740): dm message mpath2 NF fail_path 8:144 [16384]

You can say with confidence that this is device sdj.