Hi, I'm writing a userspace utility to detect/configure Medley (and later other) ataraid devices in 2.6. It's intended to run from initramfs (or initrd for those who use that). I have a couple of questions and requests for clarification. - Is there a "recommended" way to enumerate all block devices (not partitions) from userside? Since this is ATA RAID, I could of course just read the ideX majors from /proc/devices and try all the minors, but I would prefer to get a list of all detected block devices in a portable way. - After I have used the DM (and possible MD for some RAID types) to map the ataraid devices, is there a way to remove the partitions from the underlying disks from the kernel? This was my main reason for wanting to do kernel-level autodetection of these arrays, so I could prevent add_disk from being called and analysing the partition table (on these BIOS RAIDs, in striped mode the first disk contains the partition table for the entire array in sector 0, and if the user (or a script) tries to mount the partitions (or even read the extended partition table) it may try to read after the end of the disk and will in any case use wrong sector numbers - leading to possible disk corruption. On top of this it would be useful to make the underlying devices inaccessible after the mapped device is created (to prevent people from doing things like fdisk /dev/hda, when what they really wanted was something like fdisk /dev/ataraid/disc). Detecting the partition table in userspace would fix this, but it's not planned before 2.7 and I don't think it is safe to leave the false partitions exposed. - Some RAID types will need (I think) to use the MD framework as well as DM (e.g. RAID0+1), so the device the users would be the md device which would be composed of two dm devices. Is there a way to hide the underlying dm devices from the user so he they only see the ones they should use (or prevent these from being used directly some other way)? // Thomas - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
