Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

[Takahiro Yasui <tyasui@redhat.com>]

Hi Jon,

Thanks for kind comments.

Jonathan Brassow wrote:
> On Nov 25, 2008, at 6:01 PM, Takahiro Yasui wrote:
>> PATCH SET
>> =========
>>  1/4: dm-log: fix no io_client_destroy
> 
> definitely, ACK.
> 
>>  2/4: dm-log: remove unnecessary updates of io_req members
> 
> haven't fully reviewed yet.
> 
>>  3/4: dm-log: introduce multi-log devices
>>  4/4: dm-log: update interface to control multi-log devices
> 
> No.  more follows...
> 
>> BACKGROUND
>> ==========
> 
> <snip>
> 
>> However, once log disk breaks down, data replications are required
>> for a whole data disks, and if a size of data disk is huge, it
>> takes long time
> 
> Not entirely true.  When the log disk breaks down /and/ the machine  
> crashes or reboots, then resynchronization is necessary.  However,  
> this means that in almost all circumstances, you are immediately able  
> to replace the failed disk log with another and maintain the in-sync  
> state of the log - avoiding the resync.
> 
>> This patch introduces multi-log devices for mirror target, which
>> stores log data on multiple log devices, and decreases probability
>> of disk replication even if one log disk has broken down.
> 
> Given what I said above, I'd like to see intelligence added to the  
> dmeventd mirror DSO to handle replacing mirror logs done first.  There  
> is certainly a lot of low lying fruit in that space.  However, I can  
> see a small benefit to implementing multi-log.  Specifically, to  
> address the case where a log device dies and is immediately followed  
> by a machine failure before corrective action can be taken.  IOW, you  
> are targeting a very small window of time here.

Yes, as you mentioned, it is a very small window of time. But mirroring
could be used for very critical systems and users would care such
a small window.

In addition, the multi-log feature is efficient and very important
at system booting. It is highly possible that disks get broken.
I think that the current log feature can not save this situation
because there is only one log disk and there is only way to construct
a mirror by "core" log. Then, a whole disk replication will be triggered.

Do you have a good idea to save it, too? If there is, it could be
an another solution of our concern.

> If you choose to take on the multi-log (which it appears you are  
> mostly done), then I'd like to see it as a separate module.  IOW,  
> there should be no code changes to dm-log.c.  You would implement a  
> new module, named dm-log-multi[ple].ko.  The name would be "multi- 
> disk".  This frees you to have whatever constructor table arguments  
> you want.  (I've done something similar when creating my cluster-aware  
> logging.)

Yes, it is easy to implement the multi-log feature as a separate
module, but there are many common functions for both modules.
For maintainability, I think that those functions should be shared
for both modules instead of being maintained by themselves.

Could you give me any suggestions for sharing common functions?

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America) Inc.