From mboxrd@z Thu Jan 1 00:00:00 1970 From: malahal@us.ibm.com Subject: Re: [RFC][PATCH] dm-mirror: fix data corruption Date: Sun, 30 Aug 2009 12:24:41 -0700 Message-ID: <20090830192441.GA641@us.ibm.com> References: <4A568333.6090901@redhat.com> <4A5790C5.90508@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline 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 Cc: mpatocka@redhat.com List-Id: dm-devel.ids Mikulas Patocka [mpatocka@redhat.com] wrote: > > > How do bios queued in ms->failures are processed later? It seems that > > the bios stay in ms->failures forever, and the upper layer can not > > receive "success" for those bios. Don't we need a mechanism to block/unblock > > write bios to fix this issue? > > They are resubmitted with DM_ENDIO_REQUEUE on noflush suspend. My patch > has a bug that they aren't --- but I will provide a better patch, also > without this periodic polling of ms->failures queue. Trying to verify this patch. Mikulas, did you provide a better patch yet? Does this patch work at all? I would like to verify if this patch works with devices that fail temporarily. I will plan on using dm-flakey devices for testing purposes. Thanks, Malahal.