That's exactly the steps I used to test it out. The failure I encountered was at the point of adding the StripeLVs to the MirrorVG. I don't recall the error I got but I seem to recall it being the same error as if the PV hadn't been pvcreated. Although when I went through the process again just now, without any errors... It's quite likely I mistyped or skipped a step during my first attempt...
<br><br>I've gone through the whole process 4 times now from raw disk to a mirrored LV without getting the error again.<br><br>It looks as though this could work and isn't nearly as crazy as my initial configuration. I wonder now if anything wonky will happen if we were to lose a disk or in the original post if we lost one of the fabrics...
<br><br><div><span class="gmail_quote">On 12/28/06, <b class="gmail_sendername">Ty! Boyack</b> <<a href="mailto:ty@nrel.colostate.edu">ty@nrel.colostate.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Actually, I'm quite surprised that this approach mangles the lvm data.<br>It seems that when you do a pvcreate on a block device, LVM should (and<br>I think, does) write the lvm metadata in a region of that device, and
<br>then never let anything touch that metadata.  This way, if you do a 'dd<br>if=/dev/zeros of=<PV-DEVICE>' it blanks out the device, but the metadata<br>is intact.<br><br>So, if you do a 'pvcreate' on an LV, it should contain a second copy of
<br>the metadata, unique and independent from the first copy on the original<br>block device.  My tests on this has worked fine (although my tests have<br>been for building two VGs that have striped volumes across the member
<br>disks, and then a VG that creates a mirrored LV of the striped volumes,<br>so no multipathing is involved).  I'm wondering if we can compare notes<br>to see if I'm doing something that makes it look like it's working -- I
<br>don't want to be quietly destroying my lvm data and not knowing it!!!<br><br>I'm doing (roughly, block devices are a bit made-up):<br><br># prepare the physical volumes<br>pvcreate /dev/sda<br>pvcreate /dev/sdb
<br>pvcreate /dev/sdc<br>pvcreate /dev/sdd<br>pvcreate /dev/sde<br><br># Create volume groups to contain uniquely striped volumes<br>vgcreate Stripe1VG /dev/sda /dev/sdb<br>vgcreate Stripe2VG /dev/sdc /dev/sdd<br><br># Create the striped volumes
<br>lvcreate -i 2 -n Stripe1LV -L 1G Stripe1VG<br>lvcreate -i 2 -n Stripe2LV -L 1G Stripe2VG<br><br># Make the striped volumes into PVs<br>pvcreate /dev/Stripe1VG/Stripe1LV<br>pvcreate /dev/Stripe2VG/Stripe2LV<br><br># Create the volume group for mirrored volumes
<br>vgcreate MirrorVG /dev/Stripe1VG/Stripe1LV /dev/Stripe2VG/Stripe2LV /dev/sde<br># (Had to use three PVs to have the mirror log in place)<br><br># Create the mirrored volume<br>lvcreate -m 1 -n Mirror1LV -L 500M MirrorVG
<br><br># Filesystem, test, etc.  this will be GFS eventually, but testing with<br>ext3 for now.<br>mke2fs -j -i16384 -v /dev/MirrorVG/Mirror1LV<br>mkdir /mnt/mirror1lv<br>mount /dev/MirrorVG/Mirror1LV /mnt/mirror1<br><br>
<br><br>Is that about your procedure as well?  When does the lvm data get mangled?<br><br>(Sorry if this is going off topic - but if this is solvable it might<br>actually answer the original question...)<br><br>-Ty!<br><br>
<br><br><br>Matt P wrote:<br>> This is basically the "messy" way I mentioned in my reply above. I<br>> found if you pvcreate the  LV device, you end up mangling the lvm data<br>> (this probably comes as little surprise) and it breaks down after
<br>> that. So, I ended up using losetup and an "image file", one for/on<br>> each fabric. Then did pvcreate on each loop device, and made a new VG<br>> containing both PVs and created the LV with mirroring.... It
<br>> worked.... I did no performance, stability, or failure testing...<br><br><br>--<br>-===========================-<br>  Ty! Boyack<br>  NREL Unix Network Manager<br>  <a href="mailto:ty@nrel.colostate.edu">ty@nrel.colostate.edu
</a><br>  (970) 491-1186<br>-===========================-<br><br>_______________________________________________<br>linux-lvm mailing list<br><a href="mailto:linux-lvm@redhat.com">linux-lvm@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/linux-lvm">
https://www.redhat.com/mailman/listinfo/linux-lvm</a><br>read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/">http://tldp.org/HOWTO/LVM-HOWTO/</a><br></blockquote></div><br>