[dm-devel] [RFC] [PATCH] lvm2: mirroredlog support

[Jonathan Brassow]

On Sep 30, 2009, at 11:35 AM, Alasdair G Kergon wrote:

> On Wed, Sep 30, 2009 at 10:50:06AM -0500, Jon Brassow wrote:
>> As long as we are on the topic of mirror logs (and this is  
>> unrelated to
>> your patch), I'd like to complain about the current behavior of log
>> allocation vs the log policy.  I don't think it should take
>> 'alloc_anywhere' for a log to be placed on the same disk as one of  
>> the
>> mirror legs... that should be 'alloc_normal'.
>
> It was assumed that performance would be better this way, but I have
> never seen any tests to prove or disprove that.  Maybe someone could  
> run
> some?
>
> One way we could handle this is by creating a new policy between
> NORMAL and ANYWHERE that does this, then renaming the old NORMAL
> to something else and the new policy to NORMAL.

In addition to performance, I would also think that "preserving  
hardware" might be a minor priority.  You don't want to go banging  
around the heads of your hard-drives if you don't have to.

However, the user will get these benefits if they have 1 more device  
than the mirror images they are trying to create...  If not, it should  
naturally fall back to allowing the overlap of images and logs.

Inserting a new allocation level is a possibility.  I don't think it's  
necessary to solve (what I see as) the problem.  Do you have a reason  
for this?  (Remember, the change would only affect how mirrors behave  
with the various allocation policies.  If the user wanted the old  
behavior, they could get it with ALLOC_CONTIGUOUS....  However, the  
user would be stupid to choose that, because if they have enough  
disks, they will get CONTIGUOUS, and if they don't it would fail...   
Perhaps they would rather have the command fail then allow them to do  
what they are trying?)

  brassow