From: Patrick Caulfield <pcaulfie@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] vgimport/vgexport commands when logically moving disks between systems
Date: Wed, 06 Dec 2006 15:54:06 +0000 [thread overview]
Message-ID: <4576E79E.40006@redhat.com> (raw)
In-Reply-To: <478326.25880.qm@web51109.mail.yahoo.com>
Dave wrote:
> Hi Patrick, et al.
>
> Thanks for your comments!
> I've been doing some testing on this topic, and encountering a bit of strange
> behavior which seems to confirm the murkiness with switching VGs between hosts.
> Please bear with my lengthy description, as I'm trying to be as clear as possible.
> I really need to work this out.
>
> THE TEST:
>
> Hosts are P10 (primary node) and P11 (backup node)
> VG is activated on P10 and fs is mounted. To test a switch to P11, I deactivate the
> VG on P10, but DO NOT run vgexport (following your suggestion). I then, run
> vgimport on P11 (but P11 reports it already knows about the VG - that's fine), and
> then run an activate. However, when I try to run an e2fsck on the fs, I get the
> following error:
>
> /sbin/e2fsck: No such device or address while trying to open /dev/tux-ao/app
> Possibly non-existent or swap device?
>
> However, the device does exist, and looks identical to the one on P10:
> [P11]$ ls -l /dev/tux-ao/app
> brw-rw---- 1 root disk 58, 14 Dec 6 14:46 /dev/tux-ao/app
>
> I was able to fix the problem by putting vgexport back into the mix. In this case,
> I export the VG from P10 and then after an import on P11 I was able to run e2fsck
> and mount successfully.
>
> Also, this (unknown VG) message is somewhat common in pvscan, if a vgexport is not
> performed:
>
>> pvscan -- inactive PV "/dev/sdk" is associated to unknown VG "tux-ao" (run
> vgscan)
>
>
> Here is another clear example of some unexpected behavior (at least to me)...
> 1. status when $vg on P11 successful - notice the status of ACTIVE on P11 and
> EXPORTED on P10
>
> [P11]$ sudo pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> ...
> pvscan -- ACTIVE PV "/dev/sdk" of VG "tux-ao" [27.09 GB / 9.09 GB free]
>
> [P10]$ sudo pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> ...
> pvscan -- inactive PV "/dev/sdk" is in EXPORTED VG "tux-ao" [27.09 GB / 9.09 GB
> free]
>
> Then...
> 2. status after $vg is deactivated on P11 and activated on P10 (no vgexport run on
> P11 before activation on P10) - Notice the "unknown VG" message on P10!!!
>
> [P11]$ sudo pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> ...
> pvscan -- inactive PV "/dev/sdk" of VG "tux-ao" [27.09 GB / 9.09 GB free]
>
> [P10]$ sudo pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> ...
> pvscan -- inactive PV "/dev/sdk" is associated to unknown VG "tux-ao" (run vgscan)
>
> Then...
> 3. Then, when I tried an activation on P10 I get no joy at all (ie. cannot perform
> operations on the logical volume), despite the fact that it exists:
> [P10]$ ls -l /dev/tux-ao/app
> brw-rw---- 1 root disk 58, 14 Dec 6 15:04 /dev/tux-ao/app
>
> /sbin/e2fsck: No such device or address while trying to open /dev/tux-ao/app
> Possibly non-existent or swap device?
>
> Is this simply flakey behavior with LVM 1.0.8 ?
>
> We have several VGs on the machine, and sometimes we need to move one or two at a
> time. LVM (v1) seems to have trouble here, at least without vgexport. Anyone know
> what might be happening behind the scenes to cause this behavior? It's looking to
> me like I really do need vgexport to make things work the way we want.
>
> Thanks again for helping me to clarify this situation.
It's rather worrying that the two nodes seem to be reading different data from the same disks.
I can't remember off-hand whether lvm1 does direct-io when it updates metadata, possibly not.
In which case you might have to upgrade to lvm2 (which does).
lvm1 is /not/ a clustering tool ;-)
--
patrick
next prev parent reply other threads:[~2006-12-06 15:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-05 9:38 [linux-lvm] vgimport/vgexport commands when logically moving disks between systems Dave
2006-12-05 10:28 ` Patrick Caulfield
2006-12-06 15:12 ` Dave
2006-12-06 15:54 ` Patrick Caulfield [this message]
2006-12-14 13:37 ` Dave
2006-12-14 13:49 ` Patrick Caulfield
2006-12-14 15:09 ` Alasdair G Kergon
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=4576E79E.40006@redhat.com \
--to=pcaulfie@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.