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 14:22:09 -0400 [thread overview]
Message-ID: <4BC8AAD1.3050400@redhat.com> (raw)
In-Reply-To: <20100416160721.GU13021@agk-dp.fab.redhat.com>
On 04/16/10 12:07, Alasdair G Kergon wrote:
> Well current policies for -m1 with mirrored log:
> 4 areas required M1 & M2 (data); L1 & L2 (log)
>
> contiguous - 4 PVs required
> cling - same
> normal - same
> anywhere - no restriction - 1 PV may be enough.
>
> Suggestion is another policy with requirements:
> 1. L* may share PVs with M*,
> 2. M1 and M2 not on same PV as each other,
> 3. L1 and L2 not on same PV as each other.
>
> And to insert that policy between 'normal' and 'anywhere' in the sequence.
>
> There is a stronger form of 1:
> 1s. L* must share PVs with M*
> but I think we can manage without that for now because people can obtain the same
> result with this policy by listing only the PVs concerned on the command line.
> Or would it be better to implement 1s+2+3 as the first new policy?
I don't think the requirement '1s' is necessary, but But I rather
think that the policy 'normal' supports the following condition.
1. The number of PVs must be more than the number of mirror legs,
2. M1 and M2 not on same PV as each other,
3. L1 and L2 not on same PV as each other,
4. L* may share PVs with M* if the number of PVs are less than
the total number of L* and M*.
I think that some users expect that the number of mirror legs are
devices users should take care of but 'mirror log' is a logical
device LVM2 take care of.
Thanks,
Taka
next prev parent reply other threads:[~2010-04-16 18:22 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
2010-04-16 16:07 ` Alasdair G Kergon
2010-04-16 18:22 ` Takahiro Yasui [this message]
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=4BC8AAD1.3050400@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.