Closed victorstewart closed 1 year ago
Hi!
Setting received sub vol fields is implemented in the library 'for technical sake of completeness'. While it could be fun to play around with it in a test environment, do realize that this is very much a 'warranty void if seal broken' function.
So, when changing this information on a sub volume, and then using it to try receiving something else on top of it while the official tools would refuse operation, it may very well (or, most likely) result in weird errors, or outright inconsistent or corrupt results, with or without any warnings or errors. Or, you might trick the process into doing exactly what you want, but then you're happily 'living on the edge'. :-D And, do not expect to get any (official) help while dealing with the results.
It could still be fun to see the weird results and explosions, of course.
Hans
Note that btrfs incremental send is not like rdiff. It doesn't compare two arbitrary subvols and send a delta between them. It compares one subvol with an earlier version of itself and sends a delta for that. There are two main consequences of this:
It's possible to build a more general subvol-diff and subvol-patch tools (or even produce a send stream from userspace, so the subvol-patch tool could be btrfs-receive
), but it's important to understand that btrfs send
is not a subvol-diff tool.
thank you for the warnings! i ended up deciding to go a straightforward route just using a complete subvolume and constructing a container filesystem from scratch, so only the essential files are present, not the kitchen sink.
wondering if there's an easy way to change these values on the send stream encoded data of a snapshot? went down the
BTRFS_IOC_SET_RECEIVED_SUBVOL
route before realizing the fd has to be a mounted subvolume :/trying to implement something where i rebase the snapshot on a new and either identical or almost identical subvolume on another machine before calling
btrfs receive
.seems crazy to me this isn't a supported behavior.