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. I googled a bit and found related patchwork (https://patchwork.kernel.org/patch/9238987/) which seems to workaround high load in this area and mentions a real solution is proposed but not yet there. Since this affects two machines of mine and backupping my root volume would take about 80 hours in case I can extrapolate the average rate, this means btrfs send is unusable to me. Can I assume this is a common issue which will be fixed in a later kernel release (4.8, 4.9) or can I do something to my FS's to workaround this issue? One FS is only two weeks old, the other one now about 1 year. I did some balancing at some points of time to have more unallocated space for trimming, and used duperemove regularly to free space. One FS has skinny extents, the other has not. Mount options are "rw,noatime,compress=zlib,ssd,space_cache,commit=120". Apart from that: No RAID or any other special configuration involved. Cheers and any help appreciated, Oliver -- 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
