[dm-devel] [RFC][PATCH 0/4] dm-log: support multi-log devices
Takahiro Yasui
tyasui at redhat.com
Mon Dec 15 14:56:57 UTC 2008
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.
More information about the dm-devel
mailing list