[linux-lvm] LVM mirror questions

[Petr Rockai]

Hi again,

Jay <jrharris19 at yahoo.com> writes:

> Thanks for the reply.  "Should continue to work.." leaves me with some
> doubt.  My intent for a mirror is for a datastore that has reliability
> at the expense of space.  In addition, when a large datastore is
> rebooted, there would be a period of time when the data is being
> mirrored, which leaves a window of peril. After I migrate my data off
> of lvm and onto an md device, I will test lvm.

This depends on how you set up things. With the normal dmeventd
monitoring enabled, the mirror, when experiencing a log failure, will
discard the log and continue working with core log. Same for faulty
images (it'll discard the image, and depending on how many images you
have, continue as linear or with fewer images; with recent versions, you
can say in /etc/lvm/lvm.conf that you want the images/logs replaced
automatically from free PV space).

> Test #1 will be start a huge write operation on a mirror that consists
> of 2 mirrors and 1 log, all on seperate pvs.  While the write
> operation is happening, I will unplug the log drive and see if lvm
> switches in midstream to a memory log without loss.

If you have dmeventd running and the mirror volumes are monitored,
that's exactly what should happen. There might be a hitch in the IO flow
while the mirror is converted, but nothing should be lost. Please do let
us know if you observe anything else!

> Test #2 will be to see if I can make lvm activate lvs or vgs in a
> certain order.  That way I could make the first 20 extents of every
> physical device part of a vg/lv that houses mirror logs.  These log
> lvs would be mirrored across all physical devices.  The log lvs would
> have memory logs, which would be ok since they will be so small.  The
> window of peril is reduced from hours to a few seconds.

You can use --mirrorlog mirrored for that, you just need to play a bit
with the options to achieve the layout you want. Also please note that
having a log and a mirror image on the same drive may come with a
non-trivial performance penalty, since log updates now need to seek all
the way through the disk, on both images (regardless of how people think
things SHOULD work, the obvious is not always the best).

Yours,
   Petr.

PS: What happens when you don't have dmeventd running/monitoring enabled
probably depends on your kernel version. I believe it used to work in a
similar fashion without dmeventd (faulty log would be ignored), but I am
not sure that mode of operation is supported in newer versions. Someone
else might chime in knowing more about the kernel level details.