Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 13 Feb 2002 20:23:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 13 Feb 2002 20:23:41 -0500 Received: from dsl-213-023-039-092.arcor-ip.net ([213.23.39.92]:33678 "EHLO starship.berlin") by vger.kernel.org with ESMTP id ; Wed, 13 Feb 2002 20:23:23 -0500 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Andrew Morton Subject: Re: [patch] sys_sync livelock fix Date: Thu, 14 Feb 2002 02:27:39 +0100 X-Mailer: KMail [version 1.3.2] Cc: Bill Davidsen , lkml In-Reply-To:

<3C6B0A70.D11DFC2A@zip.com.au> In-Reply-To: <3C6B0A70.D11DFC2A@zip.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On February 14, 2002 01:53 am, Andrew Morton wrote: > Daniel Phillips wrote: > > > > What's the theory behind writing the data both before and after the commit? > > see fsync_dev(). It starts I/O against existing dirty data, then > does various fs-level syncy things which can produce more dirty > data - this is where ext3 runs its commit, via brilliant reverse > engineering of its calling context :-(. OK, so it sounds like cleaning that up with an ext3-specific super->sync would be cleaner for what it's worth, and save a little cpu. > It then again starts I/O against new dirty data then waits on it again. And > then again. There's quite a lot of overkill there. But that's OK, as long > as it terminates sometime. /me doesn't comment -- Daniel - 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/