All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: reiserfs-list@namesys.com
Cc: berthiaume_wayne@emc.com
Subject: beta reiserfs data logging patches
Date: 28 May 2002 16:43:51 -0400	[thread overview]
Message-ID: <1022618631.22609.1390.camel@tiny> (raw)

Hello everyone,

The very daring among you can try:

ftp.suse.com/pub/people/mason/patches/data-logging

To help me benchmark and test the new data logging code.  This is all
experimental, and should not be tried on production machines, or
anything other than a pure test box right now.

data logging helps for fsync and O_SYNC heavy applications, like mail
servers, and databases.  Without the patches, using O_SYNC writes with
iozone to make a 10MB file results in ~600K per second.  With the
patches, it goes up to around 900K/s and in data=journal mode it goes to
2300K/s.

In addition to the data logging code, there are a number of speedups for
tiny transactions.  Wayne, you are cc'd because I believe this code is
faster than the first data-logging patch, you might want to run through
the benchmarks again.

The rest of the message details the changes:

01_commit_super-8.diff -- my patch to make write_super not be used by
sync().  This has been floating around for a while and is unchanged.

02_beta-data-logging-3.diff

Adds the data=journal option, logging data blocks whenever it is one. 
This is an extension of the nesting patch used by the reiserfs quota
code.

Gets rid of the static array of struct reiserfs_journal_list.  The
structs are now allocated on demand and stored in a time ordered
per-super list.  The old code was O(N) on the size of the array in a
bunch of places, and made it very difficult to quickly find lists in
need of flushing.

The new lists allow me to quickly find transactions that haven't been
touched by kreiserfsd yet, which makes it easy to send more than one
transaction worth of metadata to disk at once.  For tiny transactions,
this makes a huge performance difference.

Since the lists are time ordered, it is also easier to figure out which
transactions the next transaction might overlap, and which ones are very
old, which cuts down on CPU time spent in do_journal_end.

-chris



             reply	other threads:[~2002-05-28 20:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-28 20:43 Chris Mason [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-28 21:37 beta reiserfs data logging patches Dieter Nützel
2002-05-28 21:48 ` Chris Mason
2002-05-29 13:01 berthiaume_wayne
2002-05-29 13:36 ` Chris Mason
2002-05-29 14:07 berthiaume_wayne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1022618631.22609.1390.camel@tiny \
    --to=mason@suse.com \
    --cc=berthiaume_wayne@emc.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.