At 09/05/2016 05:41 AM, Oliver Freyermuth wrote:
Am 30.08.2016 um 02:48 schrieb Qu Wenruo:
Yes.
And more specifically, it doesn't even affect delta backup.
For shared extents caused by reflink/dedupe(out-of-band or even incoming
in-band), it will be send as individual files.
For contents, they are all the same, just more space usage.
For those interested, I have now actually tested the btrfs send / btrfs receive
backup for several subvolumes after applying this patch.
The throughput is finally usable, almost hitting network / IO limits as
expected - ideal so far!
Also delta seemed fine for the subvolumes for which things worked.
However, I now sadly get (for one of my subvolumes):
send ioctl failed with -2: No such file or directory
at some point during the transfer, it sadly seems to be reproducible.
I do not think it's related to this patch, but of course this makes "btrfs
send" still unusable to me -
I guess it's not ready for general use just yet.
Is there any information I can easily extract / provide to allow the experts to
fix this issue?
Did you get the half way send stream?
If the send stream has something, please use "--no-data" option to send
the subvolume again to get the metadata only dump, and upload it for debug.
Also, please paste "btrfs-debug-tree -t <your subvolume id>" output for
debug.
WARN: above "btrfs-debug-tree" command will contain file names.
You could use the following sed to wipe filename:
"btrfs-debug-tree -t 5 /dev/sda6 | sed "s/name:.*//"
Thanks,
Qu
The kernel log shows nothing.
Thanks a lot,
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
