* [linux-lvm] Mirrored LVs
@ 2009-10-23 14:13 Morten Torstensen
2009-10-23 17:29 ` malahal
0 siblings, 1 reply; 8+ messages in thread
From: Morten Torstensen @ 2009-10-23 14:13 UTC (permalink / raw)
To: linux-lvm
Why cannot the mirrorlog be stored persistently in one or more LEs in
the LV? Why the need for a seperate PV for this?
Since most servers I work with have two disks for the system, this force
me to use md for mirroring, adding unneeded complexity for a simple mirror.
--
//Morten Torstensen
//Email: morten@mortent.org
//IM: morten.torstensen@gmail.com
I can't listen to that much Wagner. I start getting the urge to conquer
Poland.
-- Woody Allen
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 14:13 [linux-lvm] Mirrored LVs Morten Torstensen
@ 2009-10-23 17:29 ` malahal
2009-10-23 18:28 ` Morten Torstensen
2009-10-23 18:40 ` brem belguebli
0 siblings, 2 replies; 8+ messages in thread
From: malahal @ 2009-10-23 17:29 UTC (permalink / raw)
To: linux-lvm
Morten Torstensen [morten@mortent.org] wrote:
> Why cannot the mirrorlog be stored persistently in one or more LEs in
> the LV? Why the need for a seperate PV for this?
For better redundancy...
> Since most servers I work with have two disks for the system, this force
> me to use md for mirroring, adding unneeded complexity for a simple mirror.
Use "--alloc anywhere" to place the log LV on one of them when you
create your mirror.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 17:29 ` malahal
@ 2009-10-23 18:28 ` Morten Torstensen
2009-10-23 19:02 ` malahal
2009-10-23 18:40 ` brem belguebli
1 sibling, 1 reply; 8+ messages in thread
From: Morten Torstensen @ 2009-10-23 18:28 UTC (permalink / raw)
To: LVM general discussion and development
>> Why cannot the mirrorlog be stored persistently in one or more LEs in
>> the LV? Why the need for a seperate PV for this?
>
> For better redundancy...
In a LE it would be mirrored too and a copy would be in each mirror...
> Use "--alloc anywhere" to place the log LV on one of them when you
> create your mirror.
Yes, but this will have the side effect of not ensuring separate PVs
for the mirrored LV? An the mirror log would still not be mirrored, so
in a failure situation you would still face data loss or force a fully
resync of the mirror.
--
//Morten
//morten@mortent.org
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 17:29 ` malahal
2009-10-23 18:28 ` Morten Torstensen
@ 2009-10-23 18:40 ` brem belguebli
2009-10-23 19:15 ` malahal
1 sibling, 1 reply; 8+ messages in thread
From: brem belguebli @ 2009-10-23 18:40 UTC (permalink / raw)
To: LVM general discussion and development
2009/10/23 <malahal@us.ibm.com>:
> Morten Torstensen [morten@mortent.org] wrote:
>> Why cannot the mirrorlog be stored persistently in one or more LEs in
>> the LV? Why the need for a seperate PV for this?
>
> For better redundancy...
That is something I do not clearly see.
I am not going to enumarate em all, but mdadm stores the bitmap on
each mirror leg, HP-UX LVM store the MWC on each mirror leg .... what
makes them less redundant?
If we came to loose the LVM2 mirror third log device, what would
happen (you already answered me on this topic that the mirror would
stop).
I saw that there is some work being done to add a fourth log device to
address this SPOF.
I think the current implementation, by trying to be the MOST redundant
one, is getting too complex, or too expensive (each mirror device
requiring 3 or 4 devices even if the 1 or 2 log devices are a few
Megs) that one would, in the best case, use corelog instead, or
partition the drives to mirror with 1 small log partition and the
remaining space for data : both cases got off of the redundancy
targeted.
Worst case one would use mdadm as underlying RAID.
>
>> Since most servers I work with have two disks for the system, this force
>> me to use md for mirroring, adding unneeded complexity for a simple mirror.
>
> Use "--alloc anywhere" to place the log LV on one of them when you
> create your mirror.
>
It still requires/creates a log LV ?
> _______________________________________________
> 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/
>
Brem
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 18:28 ` Morten Torstensen
@ 2009-10-23 19:02 ` malahal
2009-10-23 19:15 ` Alasdair G Kergon
2009-10-23 19:41 ` Morten Torstensen
0 siblings, 2 replies; 8+ messages in thread
From: malahal @ 2009-10-23 19:02 UTC (permalink / raw)
To: linux-lvm
Morten Torstensen [morten@mortent.org] wrote:
> >> Why cannot the mirrorlog be stored persistently in one or more LEs in
> >> the LV? Why the need for a seperate PV for this?
> >
> > For better redundancy...
>
> In a LE it would be mirrored too and a copy would be in each mirror...
That is not possible with the current LVM code. The log can't be a
'mirror' segment. Jonathan posted few patches to place the log on
mirrored segment but the code is not in the upstream yet!
> > Use "--alloc anywhere" to place the log LV on one of them when you
> > create your mirror.
>
> Yes, but this will have the side effect of not ensuring separate PVs
> for the mirrored LV? An the mirror log would still not be mirrored, so
> in a failure situation you would still face data loss or force a fully
> resync of the mirror.
Agreed!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 19:02 ` malahal
@ 2009-10-23 19:15 ` Alasdair G Kergon
2009-10-23 19:41 ` Morten Torstensen
1 sibling, 0 replies; 8+ messages in thread
From: Alasdair G Kergon @ 2009-10-23 19:15 UTC (permalink / raw)
To: LVM general discussion and development
Specify ranges of physical extents at the end of the command line
along with --alloc anywhere to get the layout of your choosing.
e.g. lvcreate ... /dev/sdb:0-2000 /dev/sdc:0-2000 /dev/sdd:0
(Sometimes you need to force a single-extent gap to make it
do what you want, so sdb:0 sdb:2-2000 ...)
Alasdair
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 18:40 ` brem belguebli
@ 2009-10-23 19:15 ` malahal
0 siblings, 0 replies; 8+ messages in thread
From: malahal @ 2009-10-23 19:15 UTC (permalink / raw)
To: linux-lvm
brem belguebli [brem.belguebli@gmail.com] wrote:
> >> Why cannot the mirrorlog be stored persistently in one or more LEs in
> >> the LV? Why the need for a seperate PV for this?
> >
> > For better redundancy...
> That is something I do not clearly see.
> I am not going to enumarate em all, but mdadm stores the bitmap on
> each mirror leg, HP-UX LVM store the MWC on each mirror leg .... what
> makes them less redundant?
They are NOT less redundant as they store the bit map on both the legs.
Linux LVM can't place the log on both the legs at the moment so a leg
that has your log goes down, then you don't have the log data at all.
I heard another reason for not placing the log on the same PV as your
mirror leg -- performance. Since the logical block address for the log
data and the leg data will be far apart, you may cause disk seeking
back and forth. I don't know how much degradation in reality though.
A non issue when we go to SSD...
> If we came to loose the LVM2 mirror third log device, what would
> happen (you already answered me on this topic that the mirror would
> stop).
Currently either log failure or leg failure would transform your
'mirror' to a 'leaner' LV in linux. In other words, it can't handle
transient device failures at all.
> I saw that there is some work being done to add a fourth log device to
> address this SPOF.
Yes.
> I think the current implementation, by trying to be the MOST redundant
> one, is getting too complex, or too expensive (each mirror device
> requiring 3 or 4 devices even if the 1 or 2 log devices are a few
> Megs) that one would, in the best case, use corelog instead, or
> partition the drives to mirror with 1 small log partition and the
> remaining space for data : both cases got off of the redundancy
> targeted.
I understand this as some missing functionality in Linux LVM rather than
trying to make it "most redundant"...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Mirrored LVs
2009-10-23 19:02 ` malahal
2009-10-23 19:15 ` Alasdair G Kergon
@ 2009-10-23 19:41 ` Morten Torstensen
1 sibling, 0 replies; 8+ messages in thread
From: Morten Torstensen @ 2009-10-23 19:41 UTC (permalink / raw)
To: LVM general discussion and development
On 23.10.2009 21:02, malahal@us.ibm.com wrote:
>> In a LE it would be mirrored too and a copy would be in each mirror...
>
> That is not possible with the current LVM code. The log can't be a
> 'mirror' segment. Jonathan posted few patches to place the log on
> mirrored segment but the code is not in the upstream yet!
So keep the map in the vgda, with a copy on each pv, or somewhere
similar. It should just be a map of which LE is stale and doesn't have
to be big anyway.
Maybe IBM should donate some LVM code to linux :)
--
//Morten Torstensen
//Email: morten@mortent.org
//IM: morten.torstensen@gmail.com
I can't listen to that much Wagner. I start getting the urge to conquer
Poland.
-- Woody Allen
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-10-23 19:42 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-23 14:13 [linux-lvm] Mirrored LVs Morten Torstensen
2009-10-23 17:29 ` malahal
2009-10-23 18:28 ` Morten Torstensen
2009-10-23 19:02 ` malahal
2009-10-23 19:15 ` Alasdair G Kergon
2009-10-23 19:41 ` Morten Torstensen
2009-10-23 18:40 ` brem belguebli
2009-10-23 19:15 ` malahal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).