[linux-lvm] Mirrored LVs

[linux-lvm] Mirrored LVs

[Morten Torstensen]

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

Re: [linux-lvm] Mirrored LVs

[malahal]

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.

Re: [linux-lvm] Mirrored LVs

[Morten Torstensen]

>> 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

Re: [linux-lvm] Mirrored LVs

[malahal]

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!

Re: [linux-lvm] Mirrored LVs

[Alasdair G Kergon]

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

Re: [linux-lvm] Mirrored LVs

[Morten Torstensen]

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

Re: [linux-lvm] Mirrored LVs

[brem belguebli]

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

Re: [linux-lvm] Mirrored LVs

[malahal]

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"...