linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Ty! Boyack" <ty@nrel.colostate.edu>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Mirror between different SAN fabrics
Date: Thu, 28 Dec 2006 15:02:02 -0700	[thread overview]
Message-ID: <45943EDA.5080209@nrel.colostate.edu> (raw)
In-Reply-To: <859a78260612281130m761fce9rf32240b523471608@mail.gmail.com>

Actually, I'm quite surprised that this approach mangles the lvm data.  
It seems that when you do a pvcreate on a block device, LVM should (and 
I think, does) write the lvm metadata in a region of that device, and 
then never let anything touch that metadata.  This way, if you do a 'dd 
if=/dev/zeros of=<PV-DEVICE>' it blanks out the device, but the metadata 
is intact.

So, if you do a 'pvcreate' on an LV, it should contain a second copy of 
the metadata, unique and independent from the first copy on the original 
block device.  My tests on this has worked fine (although my tests have 
been for building two VGs that have striped volumes across the member 
disks, and then a VG that creates a mirrored LV of the striped volumes, 
so no multipathing is involved).  I'm wondering if we can compare notes 
to see if I'm doing something that makes it look like it's working -- I 
don't want to be quietly destroying my lvm data and not knowing it!!!

I'm doing (roughly, block devices are a bit made-up):

# prepare the physical volumes
pvcreate /dev/sda
pvcreate /dev/sdb
pvcreate /dev/sdc
pvcreate /dev/sdd
pvcreate /dev/sde

# Create volume groups to contain uniquely striped volumes
vgcreate Stripe1VG /dev/sda /dev/sdb
vgcreate Stripe2VG /dev/sdc /dev/sdd

# Create the striped volumes
lvcreate -i 2 -n Stripe1LV -L 1G Stripe1VG
lvcreate -i 2 -n Stripe2LV -L 1G Stripe2VG

# Make the striped volumes into PVs
pvcreate /dev/Stripe1VG/Stripe1LV
pvcreate /dev/Stripe2VG/Stripe2LV

# Create the volume group for mirrored volumes
vgcreate MirrorVG /dev/Stripe1VG/Stripe1LV /dev/Stripe2VG/Stripe2LV /dev/sde
# (Had to use three PVs to have the mirror log in place)

# Create the mirrored volume
lvcreate -m 1 -n Mirror1LV -L 500M MirrorVG

# Filesystem, test, etc.  this will be GFS eventually, but testing with 
ext3 for now.
mke2fs -j -i16384 -v /dev/MirrorVG/Mirror1LV
mkdir /mnt/mirror1lv
mount /dev/MirrorVG/Mirror1LV /mnt/mirror1



Is that about your procedure as well?  When does the lvm data get mangled?

(Sorry if this is going off topic - but if this is solvable it might 
actually answer the original question...)

-Ty!




Matt P wrote:
> This is basically the "messy" way I mentioned in my reply above. I
> found if you pvcreate the  LV device, you end up mangling the lvm data
> (this probably comes as little surprise) and it breaks down after
> that. So, I ended up using losetup and an "image file", one for/on
> each fabric. Then did pvcreate on each loop device, and made a new VG
> containing both PVs and created the LV with mirroring.... It
> worked.... I did no performance, stability, or failure testing...


-- 
-===========================-
  Ty! Boyack
  NREL Unix Network Manager
  ty@nrel.colostate.edu
  (970) 491-1186
-===========================-

  reply	other threads:[~2006-12-28 22:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-20 14:01 [linux-lvm] Mirror between different SAN fabrics mathias.herzog
2006-12-22 15:51 ` Matt P
2006-12-27 12:15   ` mathias.herzog
2006-12-27 20:47     ` Matt P
2006-12-28  8:12       ` mathias.herzog
2006-12-28  8:49         ` Christian.Rohrmeier
2006-12-28 10:13           ` mathias.herzog
2006-12-28 10:55             ` Christian.Rohrmeier
2006-12-28 11:09               ` Graham Wood
2006-12-28 11:31                 ` Christian.Rohrmeier
2006-12-28 11:42                   ` Graham Wood
2006-12-28 11:52                     ` mathias.herzog
2006-12-28 18:19                       ` Ty! Boyack
2006-12-28 19:30                         ` Matt P
2006-12-28 22:02                           ` Ty! Boyack [this message]
2006-12-28 23:24                             ` Matt P
2007-01-03 16:30                               ` mathias.herzog
2007-01-05 12:27                               ` mathias.herzog
2006-12-29 13:10                             ` [linux-lvm] Filter the Swap Partition berthiaume_wayne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45943EDA.5080209@nrel.colostate.edu \
    --to=ty@nrel.colostate.edu \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).