linux-ext4 - Re: [RFC] JBD ordered mode rewrite

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Mar 2008 18:38:18 +0100
From:	Jan Kara <jack@...e.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] JBD ordered mode rewrite

On Thu 06-03-08 15:53:01, Andrew Morton wrote:
> On Thu, 6 Mar 2008 18:42:09 +0100
> Jan Kara <jack@...e.cz> 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 <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html