[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Hi Jon,

Thanks for kind comments.

Jonathan Brassow wrote:
> On Nov 25, 2008, at 6:01 PM, Takahiro Yasui wrote:
>> =========
>>  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...
>> ==========
> <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?

Takahiro Yasui
Hitachi Computer Products (America) Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]