Xin Zhou posted on Sat, 24 Dec 2016 21:15:40 +0100 as excerpted: > The code is relatively new to me, I did not see retry logic in stream > handling, please correct me if I am wrong about this. > So, I am not quite sure about the transfer behavior, if the system > subject to network issues in heavy workload, > in which packets missing or connect issues are not rare. As you likely know I'm neither a dev, just a list regular and btrfs user myself, and I'm not particularly familiar with send/receive as I don't use it myself, but... AFAIK, the send and receive sides are specifically designed to be separate and to work with STDOUT/STDIN, so it's possible with STDOUT redirection to "send" to a local file instead of directly to receive, and then to replay that file on the other end by cat-ing it to receive. As such, transfer behavior isn't really a factor at the btrfs layer, since handling problems in the transfer layer is the responsibility of whatever method the user is using to do that transfer, and the user is presumed to use a transfer method with whatever reliability guarantees they deem necessary. So network behavior isn't really a factor at the btrfs level as that's the transfer layer and btrfs isn't worrying about that, simply assuming it to have the necessary reliability. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
