From: Bron Gondwana <brong@fastmail.fm>
To: Chris Mason <chris.mason@oracle.com>
Cc: debian developer <debiandev@gmail.com>,
Steven Pratt <slpratt@austin.ibm.com>,
linux-btrfs@vger.kernel.org
Subject: Re: More performance results
Date: Wed, 4 Feb 2009 13:57:29 +1100 [thread overview]
Message-ID: <20090204025729.GB2248@brong.net> (raw)
In-Reply-To: <1233673296.7246.4.camel@think.oraclecorp.com>
On Tue, Feb 03, 2009 at 10:01:36AM -0500, Chris Mason wrote:
> [...] In my testing
> here, the big difference between ext4 and btrfs isn't writing to files,
> it is actually the unlinks. If I take them out of the run, btrfs is
> very close to ext4 times.
Oh man, what is it with unlinks. Nobody does them very fast.
We use "delayed delete" with Cyrus so that the majority of unlinks
get saved for the weekend, and even then run them serially because
the IO hit is so high. We do more IO during the cyr_expire run than
even the peak of U.S. day.
A "multi-unlink" API would be seriously nice, where you could say "I
want all these files to disappear, so don't bother trying to keep making
the directory entries consistent in-between-times".
Especially, 'rm -rf' performance really sucks with single unlinks -
you're re-creating all this directory data that's just going to be
discarded in a second anyway.
Bron ( wondering how much is "it's a hard problem" and how much is
"nobody bothers to optimise it" )
next prev parent reply other threads:[~2009-02-04 2:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-02 15:58 More performance results Steven Pratt
2009-02-02 16:00 ` Chris Mason
2009-02-02 17:35 ` Steven Pratt
2009-02-03 13:32 ` debian developer
2009-02-03 14:22 ` jim owens
2009-02-03 14:56 ` Steven Pratt
2009-02-03 15:01 ` Chris Mason
2009-02-03 15:13 ` Steven Pratt
2009-02-03 16:38 ` Chris Mason
2009-02-04 2:57 ` Bron Gondwana [this message]
2009-03-16 17:06 ` Mingming Cao
-- strict thread matches above, loose matches on Subject: below --
2008-12-16 15:44 Steven Pratt
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=20090204025729.GB2248@brong.net \
--to=brong@fastmail.fm \
--cc=chris.mason@oracle.com \
--cc=debiandev@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=slpratt@austin.ibm.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