linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: liubo <liubo2009@cn.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog
Date: Fri, 06 May 2011 08:51:40 -0400	[thread overview]
Message-ID: <4DC3EEDC.30908@redhat.com> (raw)
In-Reply-To: <4DC35E99.5090600@cn.fujitsu.com>

On 05/05/2011 10:36 PM, liubo wrote:
>
> The current code relogs the entire inode every time during fsync log,
> and it is much better suited to small files rather than large ones.
>
> During my performance test, the fsync performace of large files sucks,
> and we can ascribe this to the tremendous amount of csum infos of the
> large ones, cause we have to flush all of these csum infos into log trees
> even when there are only _one_ change in the whole file data.  Apparently,
> to optimize fsync, we need to create a filter to skip the unnecessary csum
> ones, that is, the corresponding file data remains unchanged before this fsync.
>
> 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.7533Mb/sec)
>     1216.84 Requests/sec executed
>
>
> PS: I've made a _sub transid_ stuff patch, but it does not perform as effectively as this patch,
> and I'm wanderring where the problem is and trying to improve it more.
>
> Signed-off-by: Liu Bo<liubo2009@cn.fujitsu.com>
> ---
>   fs/btrfs/tree-log.c |    3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index c50271a..b934a36 100644
> --- a/fs/btrfs/tree-log.c
> +++ b/fs/btrfs/tree-log.c
> @@ -2662,6 +2662,9 @@ static noinline int copy_items(struct btrfs_trans_handle *trans,
>   			extent = btrfs_item_ptr(src, start_slot + i,
>   						struct btrfs_file_extent_item);
>
> +			if (btrfs_file_extent_generation(src, extent)<  trans->transid)
> +				continue;
> +
>   			found_type = btrfs_file_extent_type(src, extent);
>   			if (found_type == BTRFS_FILE_EXTENT_REG ||
>   			    found_type == BTRFS_FILE_EXTENT_PREALLOC) {

Seems reasonable to me,

Reviewed-by: Josef Bacik <josef@redhat.com>

Thanks,

Josef

  reply	other threads:[~2011-05-06 12:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4DAD7957.6070505@cn.fujitsu.com>
     [not found] ` <4DAE3787.8050602@cn.fujitsu.com>
     [not found]   ` <4DAE9C00.2020705@cn.fujitsu.com>
2011-05-06  2:36     ` [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog liubo
2011-05-06 12:51       ` Josef Bacik [this message]
2011-05-06 14:59       ` Chris Mason
2011-04-21  7:58 liubo
2011-04-21 13:16 ` Chris Mason
2011-04-22  0:55   ` Li Zefan
2011-04-22  1:28     ` Chris Mason
2011-04-25  9:58       ` liubo
2011-10-25 23:18         ` Myroslav Opyr
2011-10-26  1:12           ` Liu Bo

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=4DC3EEDC.30908@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).