From: malahal@us.ibm.com <malahal@us.ibm.com>
To: lvm-devel@redhat.com
Subject: [BUG-REPORT] mirror legs in the same PV with --alloc anywhere
Date: Fri, 16 Apr 2010 11:50:33 -0700 [thread overview]
Message-ID: <20100416185033.GA13043@us.ibm.com> (raw)
In-Reply-To: <4BC8AAD1.3050400@redhat.com>
Takahiro Yasui [tyasui at redhat.com] wrote:
> > 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.
I am with Taka here. The normal policy should be the default and it
should do the following for the mirroredlog without introducing a new
policy.
Requirement: Number of allocatable PV's should be at least the number of
mirror legs
Allocation: Allocate images on different PVs. Allocate logs on remaining
PVs in a round robin fashion. If there are more PV's, we
will not have to share L* and M* at all.
It would be different for disklog though:
Requirement: Number of allocatable PV's should be at least one more than
the number of mirror legs.
Allocation: Just use round-robin sequence
Thanks, Malahal.
next prev parent reply other threads:[~2010-04-16 18:50 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
2010-04-16 18:42 ` Alasdair G Kergon
2010-04-16 18:50 ` malahal [this message]
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=20100416185033.GA13043@us.ibm.com \
--to=malahal@us.ibm.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.