Thread (12 messages) 12 messages, 6 authors, 2021-10-19

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

From: David Sterba <hidden>
Date: 2021-10-19 10:52:04

On Mon, Oct 18, 2021 at 02:26:56PM -0700, Omar Sandoval wrote:
On Mon, Oct 18, 2021 at 04:41:09PM +0200, David Sterba wrote:
quoted
- set __BTRFS_SEND_C_MAX_V1 to the last command of the version or one
  beyond?
- drop UTIMES2 before release?
- naming?
If I'm understanding correctly, the main difference between this send
stream v2 and mine is the BTRFS_SEND_FLAG_VERSION flag and
btrfs_ioctl_send_args::version rather than my BTRFS_SEND_FLAG_STREAM_V2?
That's definitely a better way to do it.
Yesh, I think we should track an integer in it's own value, this would
allow us to do more updates in the future once new features appear.
The protocol version is level of stream command compatibility, while the
flags are for mode of operation (no data, encoded, ...).
What's your plan for merging this? Did you want to do this as a "trial
run" before merging the compressed send/receive stuff as protocol v3, or
did you want me to integrate these changes?
The ioctl update and versioned protocol support code can be merged to
5.16 queue, as we all seem to agree. To have something material in the
protocol the otime can be there too, enough to test the whole usecase,
without risk of getting it wrong.

V3 and following can be a bigger update, with enough time for testing.
With the versioned protocol we can do (as the worst case) one version
per release but hopefully we'll get all the current pending commands
into one version.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help