From: Jeff Mahoney <jeffm@suse.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>,
Oliver Freyermuth <o.freyermuth@googlemail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: btrfs send extremely slow (almost stuck)
Date: Tue, 30 Aug 2016 21:35:26 -0400 [thread overview]
Message-ID: <57C6345E.5010006@suse.com> (raw)
In-Reply-To: <d7346353-8e61-27b1-df2f-aabcad0580f4@cn.fujitsu.com>
[-- Attachment #1.1: Type: text/plain, Size: 1267 bytes --]
On 8/28/16 10:12 PM, Qu Wenruo wrote:
>
>
> At 08/29/2016 10:11 AM, Qu Wenruo wrote:
>>
>>
>> At 08/28/2016 11:38 AM, Oliver Freyermuth wrote:
>>> Dear btrfs experts,
>>>
>>> I just tried to make use of btrfs send / receive for incremental
>>> backups (using btrbk to simplify the process).
>>> It seems that on my two machines, btrfs send gets stuck after
>>> transferring some GiB - it's not fully halted, but instead of making
>>> full use of the available I/O, I get something < 500 kiB on average,
>>> which are just some "full speed spikes" with many seconds / minutes of
>>> no I/O in between.
>>>
>>> During this "halting", btrfs send eats one full CPU core.
>>> A "perf top" shows this is spent in "find_parent_nodes" and
>>> "__merge_refs" inside the kernel.
>>> I am using btrfs-progs 4.7 and kernel 4.7.0.
>>
>> Unknown bug, while unfortunately no good idea to solve yet.
>
> Sorry, known bug, not unknown....
I'm working on a patch to replace the lists with a pair of trees that
get merged after filling in the missing parents.
The reflink xfstests don't complete, ever. btrfs/130 triggers soft
lockups but do complete eventually -- and that's only with ~4k list
elements.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2016-08-31 1:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-28 3:38 btrfs send extremely slow (almost stuck) Oliver Freyermuth
2016-08-28 7:53 ` Duncan
2016-08-29 2:11 ` Qu Wenruo
2016-08-29 2:12 ` Qu Wenruo
2016-08-31 1:35 ` Jeff Mahoney [this message]
2016-08-31 1:54 ` Qu Wenruo
2016-08-29 10:02 ` Oliver Freyermuth
2016-08-30 0:48 ` Qu Wenruo
2016-09-04 21:41 ` Oliver Freyermuth
2016-09-05 5:21 ` Qu Wenruo
2016-09-05 21:29 ` Oliver Freyermuth
2016-09-06 2:13 ` Duncan
2016-09-06 22:24 ` Oliver Freyermuth
2016-09-06 2:46 ` Qu Wenruo
2016-09-06 21:53 ` Oliver Freyermuth
-- strict thread matches above, loose matches on Subject: below --
2016-08-28 16:15 Oliver Freyermuth
2016-08-28 21:41 ` james harvey
2016-08-29 17:50 ` Kai Krakow
2017-04-14 15:33 J. Hart
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=57C6345E.5010006@suse.com \
--to=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=o.freyermuth@googlemail.com \
--cc=quwenruo@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 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.