From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takahiro Yasui Subject: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices Date: Mon, 15 Dec 2008 09:56:57 -0500 Message-ID: <49467039.6060801@redhat.com> References: <492C91DF.7040507@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development List-Id: dm-devel.ids 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 >> ========== > > > >> 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.