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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
