knorrie / python-btrfs

Python Btrfs module
GNU Lesser General Public License v3.0
112 stars 22 forks source link

change parent_uuid and parent_transid before btrfs receive #39

Closed victorstewart closed 1 year ago

victorstewart commented 1 year ago

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.

knorrie commented 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

Zygo commented 1 year ago

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:

  1. It requires less kernel memory and runs faster than an arbitrary diff algorithm, because it can make assumptions about file differences from identifiers in the metadata, without ever looking at the data.
  2. It will happily produce garbage results without any indication of error if your use case deviates from what it was designed for.

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.

victorstewart commented 1 year ago

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.