[linux-lvm] Mirrored LVs

[malahal at us.ibm.com]

brem belguebli [brem.belguebli at 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"...