From: Jan Kara Subject: Re: [RFC] JBD ordered mode rewrite Date: Mon, 10 Mar 2008 18:38:18 +0100 Message-ID: <20080310173818.GF30435@duck.suse.cz> References: <20080306174209.GA14193@duck.suse.cz> <20080306155301.52034da0.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org To: Andrew Morton Return-path: Received: from styx.suse.cz ([82.119.242.94]:34051 "EHLO duck.suse.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751175AbYCJRiU (ORCPT ); Mon, 10 Mar 2008 13:38:20 -0400 Content-Disposition: inline In-Reply-To: <20080306155301.52034da0.akpm@linux-foundation.org> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Thu 06-03-08 15:53:01, Andrew Morton wrote: > On Thu, 6 Mar 2008 18:42:09 +0100 > Jan Kara wrote: > > > Below is my rewrite of ordered mode in JBD. Now we don't have a list of > > data buffers that need syncing on transaction commit but a list of inodes > > that need writeout during commit. This brings all sorts of advantages such > > as possibility to get rid of journal heads and buffer heads for data > > buffers in ordered mode, better ordering of writes on transaction commit, > > simplification of some JBD code, no more anonymous pages when truncate of > > data being committed happens. The patch has survived some light testing > > but it still has some potential of eating your data so beware :) I've run > > dbench to see whether we didn't decrease performance by different handling > > of truncate and the throughput I'm getting on my machine is the same (OK, > > is lower by 0.5%) if I disable the code in truncate waiting for commit to > > finish... Also the throughput of dbench is about 2% better with my patch > > than with current JBD. > > Any comments or testing most welcome. > > Thanks for plugging away with this. > > Please change your patch preparation tools to always always include a > diffstat, OK? Hmm, I mostly submit patches by hand but I'll try to not forget generate patches with git-diff --stat ;). > fs/buffer.c | 3 > fs/ext3/ialloc.c | 1 > fs/ext3/inode.c | 118 +++++++++--------- > fs/ext3/super.c | 2 > fs/jbd/checkpoint.c | 1 > fs/jbd/commit.c | 257 +++++++++++++---------------------------- > fs/jbd/journal.c | 45 +++++++ > fs/jbd/transaction.c | 288 +++++++++++----------------------------------- > fs/mpage.c | 5 > include/linux/ext3_fs.h | 1 > include/linux/ext3_fs_i.h | 1 > include/linux/jbd.h | 70 +++++++---- > include/linux/writeback.h | 2 > 13 files changed, 326 insertions(+), 468 deletions(-) > > Would it make sense to turn this patch into a patch series sometime? We can definitely split out ext3 and JBD changes (although ext3 would not compile after JBD changes). I'll have a look at what Mingming suggests - whether we could make both modes coexist reasonably easily. In that case also patches could change smaller chunks. Honza -- Jan Kara SUSE Labs, CR