From: Russell Coker <russell@coker.com.au>
To: John Goerzen <jgoerzen@complete.org>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Extremely slow metadata performance
Date: Fri, 06 Dec 2013 10:41 +1100 [thread overview]
Message-ID: <2489440.lJHvyhQY1H@xev> (raw)
In-Reply-To: <52A0BD44.9030509@complete.org>
On Thu, 5 Dec 2013 11:52:04 John Goerzen wrote:
> I have observed extremely slow metadata performance with btrfs. This may
> be a bit of a nightmare scenario; it involves untarring a backup of
> 1.6TB of backuppc data, which contains millions of hardlinks and much
> data, onto USB 2.0 disks.
How does this compare to using Ext4 on the same hardware and same data?
> I have run disk monitoring tools such as dstat while performing these
> operations to see what's going on.
>
> The behavior I notice is this:
>
> * When unpacking large files, the USB drives sustain activity in the
> 20-40 MB/s range, as expected.
> * When creating vast numbers of hardlinks instead, the activity is
> roughly this:
> o Bursts of output from tar due to -v, sometimes corresponding to
> reads in the 300KB/s range (I suspect this has
> to do with caching)
> o Tar blocked for minutes while writes to the disk occur, in the
> 300-600KB/s range.
Is iostat indicating that the disk is at 100% capacity?
> This occurs even when nobarrier,noatime are specified as mount options.
> I know the disk is capable of far more, because btrfs gets
> far more from it when writing large files.
Write speeds as low as 600KB/s isn't uncommon when there's lots of seeks.
I've seen similar performance from RAID arrays. Is BTRFS doing much worse
than Ext4 in terms of the number of seeks needed for writing that data?
> There are two USB drives in this btrfs filesystem: a 1TB and a 2TB
> drive. I have tried the raid1, raid0, and single metadata profiles.
> Anecdotal evidence suggests that raid1 performs the worst, raid0 the
> best, and single somewhere in between. The data is in single mode.
>
> Is this behavior known and expected?
Last time I did Postal tests I didn't find a lot of difference between BTRFS
and Ext4 when using 60K average file size (from memory) on a single partition.
BTRFS did worse when it was using internal RAID-1 and Ext4 was on a Linux
software RAID-1. But 60K file size may be larger than the average file you
use if you use lots of links.
For backups BTRFS seems to perform a lot better (for both creation and
removing snapshots) if you use snapshots instead of "cp -rl" or equivalent.
However I have had ongoing problems of BTRFS hanging on snapshot removal which
aren't fixed in the latest Debian packaged kernels.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
next prev parent reply other threads:[~2013-12-05 23:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 17:52 Extremely slow metadata performance John Goerzen
2013-12-05 19:39 ` Duncan
2013-12-07 9:22 ` Marc MERLIN
2013-12-07 17:10 ` Kai Krakow
2013-12-05 23:41 ` Russell Coker [this message]
[not found] ` <5930575.71jgM0vnzg@xev>
2013-12-06 4:48 ` John Goerzen
2013-12-06 14:35 ` John Goerzen
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=2489440.lJHvyhQY1H@xev \
--to=russell@coker.com.au \
--cc=jgoerzen@complete.org \
--cc=linux-btrfs@vger.kernel.org \
/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.