[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

Alasdair,

I tested the latest lvm2 and found that mirror legs were allocated
in the same PV when "--alloc anywhere" was specified. This happens
for mirrored log as well.

# /sbin/lvm.static version
  LVM version:     2.02.64(1)-cvs (2010-04-14)
  Library version: 1.02.47-cvs (2010-04-14)
  Driver version:  4.11.5
# 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 -L12m -nlv00 --mirrorlog disk --alloc anywhere vg00
  Logical volume "lv00" created
# dmsetup ls --tree
vg00-lv00 (253:3)
 |-vg00-lv00_mimage_1 (253:2)
 |  `- (8:32)
 |-vg00-lv00_mimage_0 (253:1)
 |  `- (8:32)
 `-vg00-lv00_mlog (253:0)
    `- (8:48)

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.

Is "--alloc anywhere" feature still under development? Or is this a
new behavior?

Thanks,
Taka

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Alasdair G Kergon]

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'.
(We still have some problems because the code gets the space
in two allocation requests instead of getting it all in one go, so
the first of those requests has incomplete information.)

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?

Alasdair

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

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

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Alasdair G Kergon]

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?

Alasdair

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

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

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Alasdair G Kergon]

On Fri, Apr 16, 2010 at 02:22:09PM -0400, Takahiro Yasui wrote:
> 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 was thinking of changing it to default to the new policy, and renaming that to 'normal'.
(So the old normal is the one that gets a new name.)

I'm not sure that it would be easy to implement 4 within the existing normal policy.
In general, it's hard for a single policy to work towards (and choose between)
conflicting goals.  And 'number of PVs' is not easily defined.  (We're covering
cases like -m+3 as well, plus restrictions from available PVs supplied on the
command line, plus restrictions from which PVs are already in use at different
parts of the existing mirror legs.)

Alasdair

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[malahal]

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.

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Alasdair G Kergon]

On Fri, Apr 16, 2010 at 11:50:33AM -0700, malahal at us.ibm.com wrote:
> 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.

Actually the current code allocates the logs during the first pass, not the
last, (otherwise it risks missing a 'maximal spread' layout).  Only later might
it discover there isn't enough space to complete the allocation under the
current constraints.  Then it needs to abandon the attempt, and try again with
the next, less-strict policy that allows sharing of Logs and Mimages.

Anyway, these are implementation details.  I think we agree on the goals.

Alasdair

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[brem belguebli]

I think things are not clear about this one, and everyone is confused.

Malahal (from IBM) and you have posted a few weeks ago design proposals
and patches to add mirrored log capabilities and also the fact that it
could be located on the mirror legs (pv in our cases) by using
alloc_anywhere.

alloc_anywhere, as described in the man page is to let LVM put the data
logical extents where ever it wants (not strict allocation policy) which
is, in case a mirror is expected completely a nonsense.

You may, (this is a suggestion), when lvcreating a mirror with
mirrored-log
- force strict allocation for the LE's (otherwise it' nonsense)
- put the mirrored log leg on each PV
- And may be disable alloc anywhare when creating mirrors ?

I may miss some cases (more that 2 data devices for RAID 1....)

Regards      

On Fri, 2010-04-16 at 11:19 -0400, Takahiro Yasui wrote:
> 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
> 
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

On 04/17/10 05:15, brem belguebli wrote:
> I think things are not clear about this one, and everyone is confused.

I believe that we agreed on what was our goal through this thread.

> Malahal (from IBM) and you have posted a few weeks ago design proposals
> and patches to add mirrored log capabilities and also the fact that it
> could be located on the mirror legs (pv in our cases) by using
> alloc_anywhere.
> 
> alloc_anywhere, as described in the man page is to let LVM put the data
> logical extents where ever it wants (not strict allocation policy) which
> is, in case a mirror is expected completely a nonsense.

Yes, you are right. We can't expect where logical extents are
allocated for '--alloc anywhere'

> You may, (this is a suggestion), when lvcreating a mirror with
> mirrored-log
> - force strict allocation for the LE's (otherwise it' nonsense)
> - put the mirrored log leg on each PV
> - And may be disable alloc anywhare when creating mirrors ?

I think that 'mirrored log' capability is very useful and enhancing
availability is our next step. It is helpful if users can directly
build a mirror volume, which has a mirrored log and is built on two
physical devices and also each physical device contains a mirror
leg and a mirror log, by a simple command line.

I hope this explanation would be helpful.

Thanks,
Taka

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[brem belguebli]

Yes, Thanks.

Mirrored-log allocated right on the 2 (or more) PV legs is something
we've been expecting for long now, and I'm sure I'm not the only one
in this case.

We had to hack-build our mirrored disks by layering MD over LVM, which
is not that friendly in terms of integration, MD not being
device-mapper friendly (it may have changed now) and in terms of
debugging it's not always easy.

Hope you'll get it right, that'll make a lot of people life easier.

Brem

2010/4/21 Takahiro Yasui <tyasui@redhat.com>:
> On 04/17/10 05:15, brem belguebli wrote:
>> I think things are not clear about this one, and everyone is confused.
>
> I believe that we agreed on what was our goal through this thread.
>
>> Malahal (from IBM) and you have posted a few weeks ago design proposals
>> and patches to add mirrored log capabilities and also the fact that it
>> could be located on the mirror legs (pv in our cases) by using
>> alloc_anywhere.
>>
>> alloc_anywhere, as described in the man page is to let LVM put the data
>> logical extents where ever it wants (not strict allocation policy) which
>> is, in case a mirror is expected completely a nonsense.
>
> Yes, you are right. We can't expect where logical extents are
> allocated for '--alloc anywhere'
>
>> You may, (this is a suggestion), when lvcreating a mirror with
>> mirrored-log
>> - force strict allocation for the LE's (otherwise it' nonsense)
>> - put the mirrored log leg on each PV
>> - And may be disable alloc anywhare when creating mirrors ?
>
> I think that 'mirrored log' capability is very useful and enhancing
> availability is our next step. It is helpful if users can directly
> build a mirror volume, which has a mirrored log and is built on two
> physical devices and also each physical device contains a mirror
> leg and a mirror log, by a simple command line.
>
> I hope this explanation would be helpful.
>
> Thanks,
> Taka
>
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel
>

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[brem belguebli]

Hi,

I've read in the RHEL 5.5 technical datasheet that the shipped LVM
version 2.02.56 was alraedy capable of mirrored log.

Do you confirm that , as both the man pages (lvcreate, etc...) and the
lvcreate -h do not show the option to do so.

Regards

Brem

2010/4/21 brem belguebli <brem.belguebli@gmail.com>:
> Yes, Thanks.
>
> Mirrored-log allocated right on the 2 (or more) PV legs is something
> we've been expecting for long now, and I'm sure I'm not the only one
> in this case.
>
> We had to hack-build our mirrored disks by layering MD over LVM, which
> is not that friendly in terms of integration, MD not being
> device-mapper friendly (it may have changed now) and in terms of
> debugging it's not always easy.
>
> Hope you'll get it right, that'll make a lot of people life easier.
>
> Brem
>
> 2010/4/21 Takahiro Yasui <tyasui@redhat.com>:
>> On 04/17/10 05:15, brem belguebli wrote:
>>> I think things are not clear about this one, and everyone is confused.
>>
>> I believe that we agreed on what was our goal through this thread.
>>
>>> Malahal (from IBM) and you have posted a few weeks ago design proposals
>>> and patches to add mirrored log capabilities and also the fact that it
>>> could be located on the mirror legs (pv in our cases) by using
>>> alloc_anywhere.
>>>
>>> alloc_anywhere, as described in the man page is to let LVM put the data
>>> logical extents where ever it wants (not strict allocation policy) which
>>> is, in case a mirror is expected completely a nonsense.
>>
>> Yes, you are right. We can't expect where logical extents are
>> allocated for '--alloc anywhere'
>>
>>> You may, (this is a suggestion), when lvcreating a mirror with
>>> mirrored-log
>>> - force strict allocation for the LE's (otherwise it' nonsense)
>>> - put the mirrored log leg on each PV
>>> - And may be disable alloc anywhare when creating mirrors ?
>>
>> I think that 'mirrored log' capability is very useful and enhancing
>> availability is our next step. It is helpful if users can directly
>> build a mirror volume, which has a mirrored log and is built on two
>> physical devices and also each physical device contains a mirror
>> leg and a mirror log, by a simple command line.
>>
>> I hope this explanation would be helpful.
>>
>> Thanks,
>> Taka
>>
>> --
>> lvm-devel mailing list
>> lvm-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/lvm-devel
>>
>

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

Hi Brem,

On 04/23/10 12:01, brem belguebli wrote:
> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
> version 2.02.56 was alraedy capable of mirrored log.

As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
mirrored log feature. I'm not sure which document you referred to.
Could you tell me the exact name of "RHEL 5.5 technical datasheet"?

Can we see that document in the following URL?
http://www.redhat.com/docs/manuals/enterprise/

Thanks,
Taka

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[brem belguebli]

Hi Taka,


On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
> Hi Brem,
> 
> On 04/23/10 12:01, brem belguebli wrote:
> > I've read in the RHEL 5.5 technical datasheet that the shipped LVM
> > version 2.02.56 was alraedy capable of mirrored log.
> 
> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
> mirrored log feature. I'm not sure which document you referred to.
> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?

http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
page 4, LVM

" LVM ? the Logical Volume Management storage suite has been augmented
to provide hot sparing
 for mirror journals, enabling automatic replacement or removal of
failed logging devices.
"
> 
> Can we see that document in the following URL?
> http://www.redhat.com/docs/manuals/enterprise/
> 
> Thanks,
> Taka
> 
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel

I may misunderstand the sentence, or someone at RedHat Marketing may
have written something not yet in the pipe for mainstream...

Regards

Brem	

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Takahiro Yasui]

On 04/23/10 17:09, brem belguebli wrote:
> On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
>> On 04/23/10 12:01, brem belguebli wrote:
>>> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
>>> version 2.02.56 was alraedy capable of mirrored log.
>>
>> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
>> mirrored log feature. I'm not sure which document you referred to.
>> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?
> 
> http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
> page 4, LVM
> 
> " LVM ??? the Logical Volume Management storage suite has been augmented
> to provide hot sparing
>  for mirror journals, enabling automatic replacement or removal of
> failed logging devices.
> "

Thanks for the information, but I am not sure if this sentence is
telling 'mirrored log.' What I can say is the lvm2-2.02.56-8 doesn't
have 'mirrored log' feature. I hope someone may give you a explanation...

Thanks,
Taka

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Petr Rockai]

Takahiro Yasui <tyasui@redhat.com> writes:
> On 04/23/10 17:09, brem belguebli wrote:
>> On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
>>> On 04/23/10 12:01, brem belguebli wrote:
>>>> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
>>>> version 2.02.56 was alraedy capable of mirrored log.
>>>
>>> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
>>> mirrored log feature. I'm not sure which document you referred to.
>>> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?
>> 
>> http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
>> page 4, LVM
>> 
>> " LVM ??? the Logical Volume Management storage suite has been augmented
>> to provide hot sparing
>>  for mirror journals, enabling automatic replacement or removal of
>> failed logging devices.
>> "
>
> Thanks for the information, but I am not sure if this sentence is
> telling 'mirrored log.' What I can say is the lvm2-2.02.56-8 doesn't
> have 'mirrored log' feature. I hope someone may give you a explanation...
For all I can tell, this means that if the log fails, it is
automatically replaced when there's a hotspare. Which is true, but it
does not imply mirroring.

Yours,
   Petr.

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Malahal Naineni]

Petr Rockai [prockai at redhat.com] wrote:
> Takahiro Yasui <tyasui@redhat.com> writes:
> > On 04/23/10 17:09, brem belguebli wrote:
> >> On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
> >>> On 04/23/10 12:01, brem belguebli wrote:
> >>>> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
> >>>> version 2.02.56 was alraedy capable of mirrored log.
> >>>
> >>> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
> >>> mirrored log feature. I'm not sure which document you referred to.
> >>> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?
> >> 
> >> http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
> >> page 4, LVM
> >> 
> >> " LVM ??? the Logical Volume Management storage suite has been augmented
> >> to provide hot sparing
> >>  for mirror journals, enabling automatic replacement or removal of
> >> failed logging devices.
> >> "
> >
> > Thanks for the information, but I am not sure if this sentence is
> > telling 'mirrored log.' What I can say is the lvm2-2.02.56-8 doesn't
> > have 'mirrored log' feature. I hope someone may give you a explanation...
> For all I can tell, this means that if the log fails, it is
> automatically replaced when there's a hotspare. Which is true, but it
> does not imply mirroring.

But is that new in 5.5? I thought that feature is available in 5.4 too.

Thanks, Malahal.

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[brem belguebli]

Hi Petr,



On Wed, 2010-05-05 at 16:13 +0200, Petr Rockai wrote:
> Takahiro Yasui <tyasui@redhat.com> writes:
> > On 04/23/10 17:09, brem belguebli wrote:
> >> On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
> >>> On 04/23/10 12:01, brem belguebli wrote:
> >>>> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
> >>>> version 2.02.56 was alraedy capable of mirrored log.
> >>>
> >>> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
> >>> mirrored log feature. I'm not sure which document you referred to.
> >>> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?
> >> 
> >> http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
> >> page 4, LVM
> >> 
> >> " LVM ??? the Logical Volume Management storage suite has been augmented
> >> to provide hot sparing
> >>  for mirror journals, enabling automatic replacement or removal of
> >> failed logging devices.
> >> "
> >
> > Thanks for the information, but I am not sure if this sentence is
> > telling 'mirrored log.' What I can say is the lvm2-2.02.56-8 doesn't
> > have 'mirrored log' feature. I hope someone may give you a explanation...
> For all I can tell, this means that if the log fails, it is
> automatically replaced when there's a hotspare. Which is true, but it
> does not imply mirroring.
> 
I have never seen this documented anywhere, could you provide any link
to this hotspare based log replacement?
> Yours,
>    Petr.
> 
Thanks 

Brem
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel

[BUG-REPORT] mirror legs in the same PV with --alloc anywhere

[Josh Moyer]

-----Original Message-----
From: Takahiro Yasui <tyasui@redhat.com>
Sent: April 23, 2010 12:47 PM
To: lvm-devel@redhat.com <lvm-devel@redhat.com>
Subject: Re: [lvm-devel] [BUG-REPORT] mirror legs in the same PV with --alloc anywhere


On 04/23/10 17:09, brem belguebli wrote:
> On Fri, 2010-04-23 at 14:54 -0400, Takahiro Yasui wrote:
>> On 04/23/10 12:01, brem belguebli wrote:
>>> I've read in the RHEL 5.5 technical datasheet that the shipped LVM
>>> version 2.02.56 was alraedy capable of mirrored log.
>>
>> As far as I see lvm2 code, I don't think lvm2 in RHEL5.5 has
>> mirrored log feature. I'm not sure which document you referred to.
>> Could you tell me the exact name of "RHEL 5.5 technical datasheet"?
>
> http://www.redhat.com/f/pdf/rhel/RHEL_5_5_TechOverview_wp_web.pdf
> page 4, LVM
>
> " LVM ??? the Logical Volume Management storage suite has been augmented
> to provide hot sparing
>  for mirror journals, enabling automatic replacement or removal of
> failed logging devices.
> "

Thanks for the information, but I am not sure if this sentence is
telling 'mirrored log.' What I can say is the lvm2-2.02.56-8 doesn't
have 'mirrored log' feature. I hope someone may give you a explanation...

Thanks,
Taka

--
lvm-devel mailing list
lvm-devel at redhat.com
https://www.redhat.com/mailman/listinfo/lvm-devel