From: brem belguebli <brem.belguebli@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: [linux-lvm] LVM mirror resync
Date: Wed, 23 Sep 2009 14:07:37 +0200 [thread overview]
Message-ID: <29ae894c0909230507g70719ab2ga2810256d10ae667@mail.gmail.com> (raw)
Hi,
I'm trying to find an explanation on how is handled drive failure and
how to recover a LVM mirror with on disk mirror log from this kind of
failure.
Let me explain, I have this mirrored LV composed of:
LV_mimage_0 (on /dev/mpath/mpath0p2)
LV_mimage_1 (on /dev/mpath/mpath1p2)
and
LV_mlog (on /dev/mpath/mpath0p1)
When I simulate a drive failure (echo 1 > /sys/bus/scsi/devices/
"mpath1 Lunpaths"/delete ), the PV /dev/mpath/mpath1p1 is completely
removed from the VG.
The log is also removed from the VG, though it is located on the still
present physical drive.
When disk mpath1 is back again (echo "- - -"
/sys/class/scsi_host/HOST*/scan), it appears as not belonging to any
VG:
pvs giving the following output:
...
/dev/mpath/mpath0p1 VG lvm2 a- 36.00M 36.00M
/dev/mpath/mpath0p2 VG lvm2 a- 4.95G 256.00M
/dev/mpath/mpath1p1 lvm2 -- 39.19M 39.19M
/dev/mpath/mpath1p2 lvm2 -- 4.96G 4.96G
...
LV is monitored by dmeventd.
My questions are:
1) Am I using the right method to simulate a drive failure by echoing
a scsi delete ? How would behave the scsi layer in case a disk came to
physically disappear ?
2) If the above method is correct, isn't the role of the mirror log to
keep track of region changes in case of a drive failure to be able to
incrementally resync the mirror when the missing drive is back to
operation?
Missing drive is not replaced, the UUID is the same, the problem
could have occured at scsi connectivity not on the physical media (SAN
failure for instance).
3) if so, why does disappear the log device from the VG though being
on a physically present device ?
4) when the missing drive is back again,
4-1) why does it appear as not belonging to its original VG ?
4-2) why doesn't it get automatically resync'ed by dmeventd ? .
The recover process seems to be to reconstruct from scratch the mirror
treating the failed and back again drive as a totally new drive.
Regards
next reply other threads:[~2009-09-23 12:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 12:07 brem belguebli [this message]
2009-09-24 1:26 ` [linux-lvm] LVM mirror resync malahal
2009-09-24 5:12 ` brem belguebli
2009-09-24 5:47 ` brem belguebli
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=29ae894c0909230507g70719ab2ga2810256d10ae667@mail.gmail.com \
--to=brem.belguebli@gmail.com \
--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).