All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: Leonidas Spyropoulos <artafinde@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>,
	Yan Zheng <zheng.yan@oracle.com>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Poor creat/delete files performance
Date: Wed, 18 Aug 2010 19:00:56 +0800	[thread overview]
Message-ID: <4C6BBD68.5040408@cn.fujitsu.com> (raw)
In-Reply-To: <AANLkTiktGxrm7KqhCUtts8h_jiX0UGCSygKxi06FpRn=@mail.gmail.com>

On Wed, 18 Aug 2010 11:49:16 +0100, Leonidas Spyropoulos wrote:
> Have you tried umounting and mounting before the second test to
> eliminate any caching?

Yes, I have done it.
The result is similar to the one I have reported.
(Unit: second)
   Create file performance
		BtrFS		Ext4
   Total times:	2.484392	1.505082
   Average:	0.000050	0.000030

   Delete file performance
		BtrFS		Ext4
   Total times:	3.369469	1.024886
   Average:	0.000067	0.000020


> Which kernel you use?

v2.6.35

Regards
Miao Xie

>
> 2010/8/18 Miao Xie<miaox@cn.fujitsu.com>:
>> Hi,
>>
>> We did some performance test and found the create/delete files performance
>> of btrfs is very poor.
>>
>> The test is that we create 50000 files and measure the file-create time
>> first, and then delete these 50000 files and measure the file-delete time.
>> (The attached file is the reproduce program)
>>
>> The result is following:
>> (Unit: second)
>>   Create file performance
>>                 BtrFS           Ext4
>>   Total times:  2.462625        1.449550
>>   Average:      0.000049        0.000029
>>
>>   Delete file performance
>>                 BtrFS           Ext4
>>   Total times:  3.312796        0.997946
>>   Average:      0.000066        0.000020
>>
>> The results were measured on a x86_64 server with 4 cores and 2 SAS disks.
>> By debuging, we found the btrfs spent a lot of time on searching and
>> inserting/removing items in the ctree.
>>
>> Is anyone looking at this issue?
>>
>> Regards
>> Miao Xie
>>
>
>
>


  reply	other threads:[~2010-08-18 11:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18 10:12 Poor creat/delete files performance Miao Xie
2010-08-18 10:49 ` Morten P.D. Stevens
2010-08-18 14:25   ` Chris Mason
2010-08-18 15:28     ` Morten P.D. Stevens
2010-08-18 15:39       ` Chris Mason
2010-08-18 16:26         ` Morten P.D. Stevens
2010-08-18 10:49 ` Leonidas Spyropoulos
2010-08-18 11:00   ` Miao Xie [this message]
2010-08-18 12:09 ` Chris Mason
2010-08-19  0:35   ` Miao Xie
2010-08-19  0:57     ` Chris Mason
2010-08-19  1:38       ` Miao Xie
2010-08-26 10:07       ` Miao Xie
2010-08-26 23:15         ` Chris Mason

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=4C6BBD68.5040408@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.com \
    --cc=artafinde@gmail.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zheng.yan@oracle.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.