Chris Murphy posted on Thu, 31 Dec 2015 13:54:42 -0700 as excerpted: > I haven't previously heard of this use case for -c option. > It seems to work (no errors or fs weirdness afterward). > > The gist: > send a snapshot from drive 1 to drive 2; > rw snapshot of the drive 2 copy, > and then make changes to it, > then make an ro snapshot; > now send it back to drive 1 *as an incremental* send. While as you likely know my own use-case doesn't use send/receive, based on previous on-list discussion, I considered this the obvious workaround to the problem of the current send stream format not including enough inheritance metadata to allow send/receive to properly handle a /reverse/ send -p. Where -p works, it's the most efficient method, but due to this lack of send-stream inheritance metadata, it apparently can't work in the reverse case, where the usual receive end is now the send end. But doing -c clones, while not /quite/ as efficient as -p because more metadata is sent, is still far more efficient than doing a full send, and can work in this reverse case where the original send side is now the receive side because it's not as strict as -p, being rather more metadata verbose in place of that strictness, where the -p option would fail due to strictness and lack of appropriate inheritance metadata in the stream format. That -p mode missing inheritance metadata, being effectively just one more item, would still be much more efficient than using -c clones, as the clone format is generally more metadata-verbose in ordered to properly identify per-extent clones, but it's simply not there in the current format. When the send format is eventually version-bumped, this additional metadata item should be included, making send -p work in these reverse-send cases, but they ideally want to do just one more "final" send-stream format bump including all changes they've found to be needed, so they're holding off on the format bump for the moment, so as to be able to include anything else they've overlooked when they do finally do it. That's as I understand the state of send/receive, anyway, being interested in it on-list, but not being a current user. But this usage of -c being almost precisely that "reverse-send" usage, only with an additional change thrown in at the normal receive side before the send, I'd actually have been surprised if it /didn't/ work as you outlined. =:^) -- 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
