Re: [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes

[David Sterba <dsterba@suse.cz>]

On Tue, Oct 19, 2021 at 10:38:27AM -0700, Omar Sandoval wrote:
> On Mon, Oct 18, 2021 at 04:41:09PM +0200, David Sterba wrote:

> Why do we need new commands for otime? I think it would make the most
> sense to include the BTRFS_SEND_A_OTIME attribute with an existing
> command: either the BTRFS_SEND_C_MK{DIR,FILE,NOD,FIFO,SOCK} command, or
> the first BTRFS_SEND_C_UTIME command after creation. We might as well
> take advantage of the TLV protocol, which allows us to add or remove
> attributes for commands as needed.

Yes there are more ways to extend the protocol, the patch demonstrated
two, and partially it was for me to refresh how the bits are put
together.

As long as the changes are hidden behind the version, we can insert the
attributes to existing commands, like the MKFILE group, that's a nice
trick.

On the receiving side the raw protocol is translated to the callbacks.
I've decoupled the libbtrfs implementation from the internal one, so
we're now free to do any changes to the callback prototypes without
worries to break snapper. Which means either mapping new attributes to
parameters (where we can sensibly detect "n/a") or add new callbacks
with more parameters.

I've found out that eg. the mkfile sends the inode number but it's never
parsed in receive. So for one I'd like to audit such things and write a
machine readable spec of the protocol.