From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm Date: Thu, 02 Sep 2010 12:24:03 +0200 Message-ID: <4C7F7B43.9030602@kernel.org> References: <4C7BB932.1070405@kernel.org> <4C7BD202.4040700@kernel.org> <20100830194731.GA10702@redhat.com> <4C7E36E8.2000705@kernel.org> <20100901152053.GA25644@redhat.com> <20100901170743.GB25644@redhat.com> <20100901185907.GA26411@redhat.com> <20100902032246.GA31484@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100902032246.GA31484@redhat.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: Mike Snitzer Cc: dm-devel@redhat.com, Mikulas Patocka , Vivek Goyal List-Id: dm-devel.ids Hello, On 09/02/2010 05:22 AM, Mike Snitzer wrote: >> But we can meet in the middle. I've reordered the DM FLUSH+FUA patches >> so that the more intrusive bio-based relaxed ordering patch is at the >> very end. >> >> My hope was that the request-based deadlock I'm seeing would disappear >> if that relaxed ordering patch wasn't applied. Unfortunately, I still >> see the hang. I don't think it would make any difference. AFAICS, the patch doesn't touch anything requested based dm uses. > Turns out I can reproduce the hang on a stock 2.6.36-rc3 (without _any_ > FLUSH+FUA patches)! Hmmm... that's interesting. > I'll try to pin-point the root cause but I think my test is somehow > exposing a bug in my virt setup. > > So this hang is definitely starting to look like a red herring. > > Tejun, > > This news should clear the way for you to re-post your patches. I think > it would be best if you reordered the DM patches like I did here in this > series: http://people.redhat.com/msnitzer/patches/flush-fua/series > > In particular, the dm-relax-ordering-of-bio-based-flush-implementation > patch should go at the end. I think it makes for a more logical > evolution of the DM code. Sure, I'll. I still think having the queue kicking mechanism is a good idea tho. I'll integrate that into series, reorder and repost it. Thanks. -- tejun