From: Josef Bacik <josef@redhat.com>
To: Liu Bo <liubo2009@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, chris.mason@oracle.com
Subject: Re: [PATCH 0/9] Btrfs: improve write ahead log with sub transaction
Date: Mon, 23 May 2011 12:43:23 -0400 [thread overview]
Message-ID: <4DDA8EAB.9050805@redhat.com> (raw)
In-Reply-To: <1305792692-10635-1-git-send-email-liubo2009@cn.fujitsu.com>
On 05/19/2011 04:11 AM, Liu Bo wrote:
> I've been working to try to improve the write-ahead log's performance,
> and I found that the bottleneck addresses in the checksum items,
> especially when we want to make a random write on a large file, e.g a 4G file.
>
> Then a idea for this suggested by Chris is to use sub transaction ids and just
> to log the part of inode that had changed since either the last log commit or
> the last transaction commit. And as we also push the sub transid into the btree
> blocks, we'll get much faster tree walks. As a result, we abandon the original
> brute force approach, which is "to delete all items of the inode in log",
> to making sure we get the most uptodate copies of everything, and instead
> we manage to "find and merge", i.e. finding extents in the log tree and merging
> in the new extents from the file.
>
> This patchset puts the above idea into code, and although the code is now more
> complex, it brings us a great deal of performance improvement.
>
> Beside the improvement of log, patch 8 fixes a small but critical bug of log code
> with sub transaction.
>
> Here I have some test results to show, I use sysbench to do "random write + fsync".
>
> ===
> sysbench --test=fileio --num-threads=1 --file-num=2 --file-block-size=4K --file-total-size=8G --file-test-mode=rndwr --file-io-mode=sync --file-extra-flags= [prepare, run]
> ===
>
> Sysbench args:
> - Number of threads: 1
> - Extra file open flags: 0
> - 2 files, 4Gb each
> - Block size 4Kb
> - Number of random requests for random IO: 10000
> - Read/Write ratio for combined random IO test: 1.50
> - Periodic FSYNC enabled, calling fsync() each 100 requests.
> - Calling fsync() at the end of test, Enabled.
> - Using synchronous I/O mode
> - Doing random write test
>
> Sysbench results:
> ===
> Operations performed: 0 Read, 10000 Write, 200 Other = 10200 Total
> Read 0b Written 39.062Mb Total transferred 39.062Mb
> ===
> a) without patch: (*SPEED* : 451.01Kb/sec)
> 112.75 Requests/sec executed
>
> b) with patch: (*SPEED* : 4.3621Mb/sec)
> 1116.71 Requests/sec executed
>
Have you run powerfail tests with this? I'd like to make sure you
haven't inadvertently messed something up. Thanks,
Josef
next prev parent reply other threads:[~2011-05-23 16:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 8:11 [PATCH 0/9] Btrfs: improve write ahead log with sub transaction Liu Bo
2011-05-19 8:11 ` [PATCH 1/9] Btrfs: introduce sub transaction stuff Liu Bo
2011-05-20 0:23 ` Chris Mason
2011-05-20 0:53 ` liubo
2011-05-23 14:40 ` Chris Mason
2011-05-25 3:56 ` liubo
2011-05-25 10:21 ` liubo
2011-05-24 11:34 ` Chris Mason
2011-05-26 2:48 ` liubo
2011-05-19 8:11 ` [PATCH 2/9] Btrfs: update block generation if should_cow_block fails Liu Bo
2011-05-19 8:11 ` [PATCH 3/9] Btrfs: modify btrfs_drop_extents API Liu Bo
2011-05-19 8:11 ` [PATCH 4/9] Btrfs: introduce first sub trans Liu Bo
2011-05-19 8:11 ` [PATCH 5/9] Btrfs: still update inode trans stuff when size remains unchanged Liu Bo
2011-05-19 8:11 ` [PATCH 6/9] Btrfs: improve log with sub transaction Liu Bo
2011-05-19 8:11 ` [PATCH 7/9] Btrfs: add checksum check for log Liu Bo
2011-05-19 8:11 ` [PATCH 8/9] Btrfs: fix a bug of log check Liu Bo
2011-05-19 8:11 ` [PATCH 9/9] Btrfs: kick off useless code Liu Bo
2011-05-19 8:14 ` [PATCH 0/9] Btrfs: improve write ahead log with sub transaction liubo
2011-05-23 16:43 ` Josef Bacik [this message]
2011-05-24 1:29 ` liubo
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=4DDA8EAB.9050805@redhat.com \
--to=josef@redhat.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.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.