From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [PATCH, RFC] simplify writeback thread creation Date: Fri, 09 Jul 2010 10:52:59 +0300 Message-ID: <1278661979.9953.8.camel@localhost> References: <20100707225242.GA28802@lst.de> <4C35C292.9020507@kernel.dk> <1278598877.20321.34.camel@localhost> <4C35E7D5.8020809@kernel.dk> <1278602632.9953.4.camel@localhost> <4C360998.9040609@kernel.dk> <1278614602.7365.8.camel@localhost.localdomain> <20100708184811.GA17593@lst.de> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jens Axboe , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from smtp.nokia.com ([192.100.122.233]:34189 "EHLO mgw-mx06.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753133Ab0GIH5N (ORCPT ); Fri, 9 Jul 2010 03:57:13 -0400 In-Reply-To: <20100708184811.GA17593@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2010-07-08 at 20:48 +0200, Christoph Hellwig wrote: > On Thu, Jul 08, 2010 at 09:43:22PM +0300, Artem Bityutskiy wrote: > > Hmm, was thinking about this while driving home - the forker approa= ch > > has a good resilience property - if it cannot fork - it'll do the s= tuff > > itself. I have a feeling that if something like this to be implemen= ted > > with the approach I suggested, we'll end up with similar level of > > complexity that we wanted to get rid of... >=20 > Yes, the lazy starting is what adds the complexity. I think starting > it once we have any filesystem mounted on the bdi and stop it once al= l > filesystems are gone is a lot simpler and more elegant. But what about cases like 'dd if=3D/dev/zero of=3D/dev/sda4'? They also involve dirty data write-back. --=20 Best Regards, Artem Bityutskiy (=D0=90=D1=80=D1=82=D1=91=D0=BC =D0=91=D0=B8=D1=82=D1=8E= =D1=86=D0=BA=D0=B8=D0=B9) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html