All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takahiro Yasui <tyasui@redhat.com>
To: lvm-devel@redhat.com
Subject: [BUG-REPORT] mirror legs in the same PV with --alloc anywhere
Date: Fri, 16 Apr 2010 11:19:30 -0400	[thread overview]
Message-ID: <4BC88002.10803@redhat.com> (raw)
In-Reply-To: <20100415220308.GO13021@agk-dp.fab.redhat.com>

On 04/15/10 18:03, Alasdair G Kergon wrote:
> On Thu, Apr 15, 2010 at 05:13:34PM -0400, Takahiro Yasui wrote:
>> I tested the latest lvm2 and found that mirror legs were allocated
>> in the same PV when "--alloc anywhere" was specified. 
> 
> That is correct - it is what 'anywhere' means - it is OK for the tools
> to take the space from 'anywhere'.

Understand. (I was a bit confused because the behavior of 'anywhere'
got changed.)

As for a mirror volume with 'mirrored' log, it is simpler to prepare
two physical disks and create a mirror volume with 'mirrored log' in
two disks. In this case, I expect that each disk has one of mirror legs
one of mirror logs. I was thinking that '--alloc anywhere' was used
to build this kind of mirror volumes.

This is an example case.

# pvs
  PV         VG   Fmt  Attr PSize  PFree
  /dev/sdc   vg00 lvm2 a-   16.00G 16.00G
  /dev/sdd   vg00 lvm2 a-   16.00G 16.00G
# lvcreate -m1 -L1g -nlv00 --mirrorlog mirrored --alloc anywhere vg00
  Logical volume "lv00" created
# dmsetup ls --tree
vg00-lv00 (253:5)
 |-vg00-lv00_mimage_1 (253:4)
 |  `- (8:32)
 |-vg00-lv00_mimage_0 (253:3)
 |  `- (8:32)
 `-vg00-lv00_mlog (253:2)
    |-vg00-lv00_mlog_mimage_1 (253:1)
    |  `- (8:32)
    `-vg00-lv00_mlog_mimage_0 (253:0)
       `- (8:48)

Now I undestand that '--alloc anywhere' is not designed for this purpose
and we need to use the workaround I described in the previous mail as
below.

> The workaround in this case is to create a mirror device with a core
> log, and then to convert it to a mirror with a disk log.


> Are there any likely situations where a non-optimal layout is selected
> with --alloc normal?  If so, can we identify them and find some strategy
> to handle it e.g. do we need to add another allocation policy 
> to allow logs on the same PVs as mimages?

I don't have an issue of '--alloc normal' so far.

Thanks,
Taka



  reply	other threads:[~2010-04-16 15:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-15 21:13 [BUG-REPORT] mirror legs in the same PV with --alloc anywhere Takahiro Yasui
2010-04-15 22:03 ` Alasdair G Kergon
2010-04-16 15:19   ` Takahiro Yasui [this message]
2010-04-16 16:07     ` Alasdair G Kergon
2010-04-16 18:22       ` Takahiro Yasui
2010-04-16 18:42         ` Alasdair G Kergon
2010-04-16 18:50         ` malahal
2010-04-16 19:06           ` Alasdair G Kergon
2010-04-17  9:15     ` brem belguebli
2010-04-21 15:18       ` Takahiro Yasui
2010-04-21 17:36         ` brem belguebli
2010-04-23 16:01           ` brem belguebli
2010-04-23 18:54             ` Takahiro Yasui
2010-04-23 21:09               ` brem belguebli
2010-04-23 19:49                 ` Takahiro Yasui
2010-05-05 14:13                   ` Petr Rockai
2010-05-05 14:35                     ` Malahal Naineni
2010-05-06  1:44                     ` brem belguebli
  -- strict thread matches above, loose matches on Subject: below --
2010-04-23 20:01 Josh Moyer

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=4BC88002.10803@redhat.com \
    --to=tyasui@redhat.com \
    --cc=lvm-devel@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.