Bug 222787
Summary: | lvm picks up md component devices automatically | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Robin Panda <pand0008> |
Component: | lvm2 | Assignee: | Petr Rockai <prockai> |
Status: | CLOSED WORKSFORME | QA Contact: | Corey Marthaler <cmarthal> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | agk, dwysocha, jbrassow, mbroz, prockai |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-04-04 09:15:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Robin Panda
2007-01-16 07:49:57 UTC
As far as i recall, running lvm on top of md is not recommended (although i have no idea if this is mentioned anywhere in the documentation). You should always blacklist md-participating devices in your lvm.conf to avoid lvm picking them up. I don't think partition type check is sufficient or even a good idea, since someone issuing pvcreate /dev/foo3, where foo3 previously held say ext3 and was of type Linux, usually does not bother to fdisk the drive and flip partition types, yet he probably does not want next boot to fail due to incomplete volume group (since foo3 is excluded, being of non-lvm partition type). What -could- work is adding md metadata detection and refusing to use devices that have md signature on them (maybe unless forced). Thoughts, comments? There is already md component detection, see lvm.conf # By default, LVM2 will ignore devices used as components of # software RAID (md) devices by looking for md superblocks. # 1 enables; 0 disables. md_component_detection = 1 Confirming that the md component detection works as it should. [root@dhcp-lab-168 ~]# mdadm --assemble /dev/md0 mdadm: /dev/md0 has been started with 1 drive (out of 2). [root@dhcp-lab-168 ~]# pvscan PV /dev/md0 VG vg0 lvm2 [5.99 GB / 5.95 GB free] Total: 1 [5.99 GB] / in use: 1 [5.99 GB] / in no VG: 0 [0 ] [root@dhcp-lab-168 ~]# mdadm --stop /dev/md0 mdadm: stopped /dev/md0 [root@dhcp-lab-168 ~]# pvscan No matching physical volumes found [root@dhcp-lab-168 ~]# vgchange -a y No volume groups found Let me try to put root partition on an lv atop md to see if initrd adds some confusion to the equation. I do not recall any specific warnings against this, although that doesn't mean there weren't any as I might not have read it or remembered because I originally set up the LVM years ago (although originally with the plans of easy moving to raid later) and only set up the raid drives in January. I do crazy things anyway, like run raid on top of raid. Though that made sense at the time too, two 8.4GB 5400rpm drives striped together and then mirrored against a 7200rpm 20gb drive. My lvm.conf contains md_component_detection = 1 as does the one in my initrd (which brings me to another issue, the mkinitrd in fc5 doesn't seem to figure out to use raid456 for raid5, but I just pulled in the fc6 version). I haven't had the chance to check out what the fc6 live cd has, perhaps that's where the fault lies. That sounds possible, i have checked the codepaths in lvm2 and they look all right, the test above worked as expected, so i am closing this as WORSKFORME, if you run into the problem again, please check if md_component_detection in the relevant configuration file is turned on and if so, reopen this report. Thanks. |