Created attachment 619982 [details] PATCH Description of problem: lvm.conf has a setting called md_component_detection, which makes lvm ignore disks with a linux "md" raid superblock. This patch adds detection of more raid superblock formats, ddf and imsm. Version-Release number of selected component (if applicable): LVM2-2.02.97 Additional info: This was discussed on the linux-lvm mailinglist in Spetember 2012, Subject "automatically filter disks with imsm or ddf superblocks". This is v3 of the patch, as posted on 22-09-2012.
Is this patch ok ? Are we going to add more and more built-in detections or we outsource this into util-linux binaries ?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
In util-linux/libblkid/src/superblocks/ there are already checks for both "DDF" and "ISW" (aka Intel Matrix / Intel Software Raid / Rapid Storage / etc.) in ddf_raid.c and isw_raid.c respectively. Thus one can query for superblock types with libblkid.
It's more complex. lvm2 should probably be able to use udev database here, which already keeps the info - so as soon as udev is used - it should be used for more things than just obtaining list of devices.
(In reply to Zdenek Kabelac from comment #4) > It's more complex. > > lvm2 should probably be able to use udev database here, which already keeps > the info - so as soon as udev is used - it should be used for more things > than just obtaining list of devices. ...I agree - it would make the existing filtering even faster (md, mpath,partitioned dev) as the scan and variables are already set in udev (based on blkid call and some additional processing by each subsystem's rules). Also, the mpath filtering would work even better as we don't know whether the device is an mpath member or not until the mpath device is fully set up. But mpath itself already knows which device is going to be a part of the top-level mpath device and it marks such devices in udev already. So these are the arguments for giving the udev db a try I think... The only danger here is that sometimes we encountered problems while reading udev db with older versions of libudev where races were still present directly in libudev interface. But we could just enable it for those newer versions, of course.
There've been some enhancements since that last comment was written. Let's re-evaluate the situation.
I can see the appeal of using libblkid or similar instead of one-off solutions like this patch. I see that libblkid based wiping has already been added in dev/dev-type.c. Should similar support be added to filters/filter-md.c ? Or a new filters/filter-blkid.c ?
Yes, we'd definitely like to reuse the existing information in the system instead of doing the scans again (there's at least the blkid cache as well as udev information that already has what we need). I'll certainly revisit this - but at the moment I'm a bit overloaded with other high prio bugs to resolve, unfortunately. I'll try to get to this as soon as possible - this should be easy to add so once I've more time... I should be able to prepare patches for this quickly then.
The patchset that uses udev db info for filtering is now upstream (lvm2 version 2.02.116). To use this feature, you need to enable it by setting following items in lvm.conf: devices { external_device_info_source = "udev" fw_raid_component_detection = 1 }