linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Miao Xie <miaox@cn.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Josef Bacik <JBacik@fusionio.com>
Subject: Re: [RFC][PATCH 2/2] Btrfs: implement unlocked dio write
Date: Thu, 31 Jan 2013 11:42:31 -0500	[thread overview]
Message-ID: <20130131164231.GQ3660@localhost.localdomain> (raw)
In-Reply-To: <510A3BB7.4090201@cn.fujitsu.com>

On Thu, Jan 31, 2013 at 02:39:03AM -0700, Miao Xie wrote:
> This idea is from ext4. By this patch, we can make the dio write parallel,
> and improve the performance.
> 
> We needn't worry about the race between dio write and truncate, because the
> truncate need wait untill all the dio write end.
> 
> And we also needn't worry about the race between dio write and punch hole,
> because we have extent lock to protect our operation.
> 
> I ran fio to test the performance of this feature.
> 
> == Hardware ==
> CPU: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
> Mem: 2GB
> SSD: Intel X25-M 120GB (Test Partition: 60GB)
> 
> == config file ==
> [global]
> ioengine=psync
> direct=1
> bs=4k
> size=32G
> runtime=60
> directory=/mnt/btrfs/
> filename=testfile
> group_reporting
> thread
> 
> [file1]
> numjobs=1 # 2 4
> rw=randwrite
> 
> == result (KBps) ==
> write	1	2	4
> lock	24936	24738	24726
> nolock	24962	30866	32101
> 
> == result (iops) ==
> write	1	2	4
> lock	6234	6184	6181
> nolock	6240	7716	8025

So the one thing I worry about is interactions with fsync.  I've been depending
on the mutex to keep us from getting screwed by writers coming in while I'm
trying to write out the changed extents.  Could you test this with fsync and
make sure it doesn't break anything?  Thanks,

Josef

  reply	other threads:[~2013-01-31 16:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31  9:39 [RFC][PATCH 2/2] Btrfs: implement unlocked dio write Miao Xie
2013-01-31 16:42 ` Josef Bacik [this message]
2013-02-01  2:53 ` Liu Bo
2013-02-01  4:08   ` Miao Xie
2013-02-01  7:39     ` Miao Xie

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=20130131164231.GQ3660@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@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).