All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinz Mauelshagen <heinzm@redhat.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] LVM RAID1 syncing component
Date: Thu, 27 Nov 2014 13:52:19 +0100	[thread overview]
Message-ID: <54771E83.2090003@redhat.com> (raw)
In-Reply-To: <20141126082055.72680602@jlaw-desktop.mno.stratus.com>


With DM/LVM it is always the last images added when converting (to)
raid1; see "lvs -a".

If you for instance convert from linear to raid1 with "lvconvert -m1 
--type raid1  $LV",
the second (and last) device named /dev/$VG/${LV}_rimage_1 will be 
resynchronized
from the first /dev/$VG/${LV}_rimage_0 (i.e. the former linear device).

As mentioned below, the copy_percent aka sync_percent tells you how far 
the sync process got
unless 100% when it's finished.

-- lvmguy


On 11/26/2014 02:20 PM, Joe Lawrence wrote:
> On Tue, 25 Nov 2014 22:42:38 -0700
> Chris Murphy <lists@colorremedies.com> wrote:
>
>> On Mon, Nov 24, 2014 at 9:07 PM, Joe Lawrence <joe.lawrence@stratus.com> wrote:
>>> Does anyone know how its possible to determine which side of an LVM RAID 1
>>> is the stale partner during RAID resync?
>>>
>>> In ordinary MD RAID, I believe you can check
>>> /sys/block/md0/md/dev-XXX/state, but LVM RAID seems to hide those files
>>> when leveraging the MD code.  I've looked though pvs/vgs/lvs manpages, but
>>> can't figure anything out there either.
>> Rather indirectly: iotop which will show you which devices are mostly
>> being read from and written to.
>>
>> # lvs -a -o copy_percent
>> Anything less than 100% is syncing. I think.
>>
> >From the manpages I see the following attribute bits:
>
> * lvs, lv_attr bit Volume Health: (p)artial
> * vgs, vg_attr bit (p)artial: one or more physical volumes belonging
>         to the volume group are missing from the system
> * pvs, pv_attr bit (m)issing
>
> along with the lvs copy_percent (is this similar to sync_percent) that
> you mentioned.  That's about it.
>
> Since there seems to be no real underlying MD device, I'm assuming that
> ioctls are out of the question as well.
>
> -- Joe
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  reply	other threads:[~2014-11-27 12:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25  4:07 LVM RAID1 syncing component Joe Lawrence
2014-11-26  5:42 ` Chris Murphy
2014-11-26 13:20   ` [linux-lvm] " Joe Lawrence
2014-11-26 13:20     ` Joe Lawrence
2014-11-27 12:52     ` Heinz Mauelshagen [this message]
2014-11-26 20:41 ` NeilBrown
2014-11-29 15:26   ` Peter Grandi
2014-12-01 23:28     ` NeilBrown
2014-12-01 21:19   ` Joe Lawrence
2014-12-01 21:27     ` Joe Lawrence
2014-12-01 21:41     ` NeilBrown
2014-12-02 19:05       ` Joe Lawrence

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=54771E83.2090003@redhat.com \
    --to=heinzm@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.