From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH, RFC] simplify writeback thread creation Date: Fri, 09 Jul 2010 10:16:40 +0200 Message-ID: <4C36DAE8.3070302@kernel.dk> 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> <1278661979.9953.8.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: dedekind1@gmail.com Return-path: Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:50395 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753088Ab0GIIQm (ORCPT ); Fri, 9 Jul 2010 04:16:42 -0400 In-Reply-To: <1278661979.9953.8.camel@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2010-07-09 09:52, Artem Bityutskiy wrote: > 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 approach >>> has a good resilience property - if it cannot fork - it'll do the stuff >>> itself. I have a feeling that if something like this to be implemented >>> with the approach I suggested, we'll end up with similar level of >>> complexity that we wanted to get rid of... >> >> 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 all >> filesystems are gone is a lot simpler and more elegant. > > But what about cases like 'dd if=/dev/zero of=/dev/sda4'? They also > involve dirty data write-back. You would have to do it at device open time, if the thread does not already exist. Not sure this is all worth it, I think the complexity of the lazy create/exit is a bit exaggerated. -- Jens Axboe