Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755848AbYGDMJW (ORCPT ); Fri, 4 Jul 2008 08:09:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753001AbYGDMJJ (ORCPT ); Fri, 4 Jul 2008 08:09:09 -0400 Received: from TYO202.gate.nec.co.jp ([202.32.8.206]:34168 "EHLO tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752982AbYGDMJH (ORCPT ); Fri, 4 Jul 2008 08:09:07 -0400 Message-Id: From: "Takashi Sato" To: "Eric Sandeen" , "Alasdair G Kergon" , "Dave Chinner" Cc: , , "Andrew Morton" , , , , "Christoph Hellwig" , , , References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> <20080703124709.GI22522@agk.fab.redhat.com> <20080703221133.GA29319@disturbed> In-Reply-To: <20080703221133.GA29319@disturbed> Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Date: Fri, 4 Jul 2008 21:08:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1957 Lines: 49 Hi Alasdair, Eric and Dave, > On Thu, Jul 03, 2008 at 01:47:10PM +0100, Alasdair G Kergon wrote: >> On Thu, Jul 03, 2008 at 09:11:05PM +0900, Takashi Sato wrote: >> > If the freezer accesses the frozen filesystem and causes a deadlock, >> > the above ideas can't solve it >> >> But you could also say that if the 'freezer' process accesses the frozen >> filesystem and deadlocks then that's just a bug and that userspace code >> should be fixed and there's no need to introduce the complexity of a >> timeout parameter. > > Seconded - that was also my primary objection to the timeout code. I will consider removing the timeout. >> The point I'm trying to make here is: >> Under what real-world circumstances might multiple concurrent freezing >> attempts occur, and which of A, B or C (or other variations) would be >> the most appropriate way of handling such situations? >> >> A common example is people running xfs_freeze followed by an lvm command >> which also attempts to freeze the filesystem. > > Yes, I've seen that reported a number of times. > >> I can see a case for B or C, but personally I prefer A: >> >> > > 1 succeeds, freezes >> > > 2 succeeds, remains frozen >> > > 3 succeeds, remains frozen >> > > 4 succeeds, thaws > > Agreed, though I'd modify the definition of that case to be "remain > frozen until the last thaw occurs". That has the advantage that > it's relatively simple to implement with just a counter... I agree this idea. But I have one concern. When device-mapper's freeze follows FIFREEZE, can device-mapper freeze only device-mapper's part correctly? And when device-mapper's thaw follows FITHAW, can device-mapper thaw only device-mapper's part? Cheers, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/