>Unless there are bugs that >would show up in other situations as well (or an out-of-space condition >is triggered that would likewise show up in other situations with a >similar amount of data/metadata written), That is exactly some bugs come from. For simple cases, it is ok to assume the send/receive always succeed. And if it errors out, assumes the delete always succeed, and the file system is in consistent status, and good luck with the data. Xin Sent: Sunday, December 25, 2016 at 7:52 PM From: Duncan <1i5t5.duncan@xxxxxxx> To: linux-btrfs@xxxxxxxxxxxxxxx Subject: Re: [CORRUPTION FILESYSTEM] Corrupted and unrecoverable file system during the snapshot receive Xin Zhou posted on Mon, 26 Dec 2016 03:36:09 +0100 as excerpted: > One interesting thing to investigate might be the btrfs send / receive > result, under a disruptive network environment. If the connection breaks > in the middle of transfer (at different phase, maybe), see what could be > the file system status. Btrfs send, sends from a read-only snapshot, so the sending filesystem shouldn't be harmed no matter what happens to send. Btrfs receive does all its work in a new subvolume (basically a snapshot in an incremental send, tho I'm not sure it's a full snapshot in the technical sense), modifying the files therein using standard calls used in other contexts as well, so absent bugs that should appear in those other contexts too if they exist, the worst damage that a receive should be able to do is an unfaithful replay of the send stream, such that an appropriate copy of the sent snapshot doesn't appear on the receiver. Which means even in the case of error, cleanup is as simple as deleting the aborted/incompletely-received subvolume. Unless there are bugs that would show up in other situations as well (or an out-of-space condition is triggered that would likewise show up in other situations with a similar amount of data/metadata written), there should be no effects outside that received subvolume. -- 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 -- 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
