At 08/31/2016 09:35 AM, Jeff Mahoney wrote:
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.
Wow, nice.
I was planning to do it but didn't get started yet.
The list is really causing the problem.
Converting to rb_tree should at least reduce the O(n^3)~O(n^4)
to O(n^2logn).
While the backref walk call in the loop of iterating every file extents
is never a good idea for me, I'll still try to fix at the send side as
an RFC patch too.
Thanks,
Qu
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
