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, 05 Jan 2009 12:36:12 -0500 Message-ID: <4962450C.20507@redhat.com> References: <492C91DF.7040507@redhat.com> <49467039.6060801@redhat.com> <20081220001305.GA8574@us.ibm.com> <49502F7E.9040300@redhat.com> <20081223180228.GA24831@us.ibm.com> <49622ADB.7040200@redhat.com> <20090105162435.GB18452@us.ibm.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090105162435.GB18452@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: malahal@us.ibm.com Cc: dm-devel@redhat.com, agk@redhat.com List-Id: dm-devel.ids malahal@us.ibm.com wrote: > Takahiro Yasui [tyasui@redhat.com] wrote: >> Hi Malahal, >> >> my patch doesn't handle transient error now. I expect log devices >> to be failed and got in a blockage status once an error has happened. >> >>> With our user level only implementation, the log device handling would >>> be as good as the real mirror *leg* handling. We get all the benefits of >>> the mirror without doing any code! Wouldn't it be nice? >> I agree that simple implementation is better, but log could be handled >> without any additional layer, and also I'm thinking that log could be >> handled in the simpler way. >> >> Lower layer, such as SCSI, also has retry feature based on error type >> and will be done in the proper way. Do you mean that it isn't enough >> and should dm-layer handle errors for log device, too? > > Not really. What I meant is re-integrating a failed log device when it > comes back again. That is also what I mean by handling 'transient > errors'. Thanks, I see your requirement on this feature. Let me put one more question. LVM mirroring is used to make system available even if some devices, such as data and log device, have a problem. Currently, activations by "vgchange -ay" command seem to fail during system booting if one of devices related to VG are missing or had I/O error. For example, if a mirror is structured by two data devices and log devices, the mirror logical device should be activated and used even if one data device and one log device are missing. Could you give me an idea or solution to handle this? Do we need to enhance your feature to achieve this requirement? I appreciate your comments. Thanks, Taka