Re: [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes
From: David Sterba <hidden>
Date: 2021-10-19 20:26:06
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.