public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, nborisov@suse.com
Subject: Re: [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes
Date: Tue, 19 Oct 2021 12:51:34 +0200	[thread overview]
Message-ID: <20211019105133.GQ30611@suse.cz> (raw)
In-Reply-To: <YW3moPgbBMQhN7XY@relinquished.localdomain>

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:
> > - 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.

  reply	other threads:[~2021-10-19 10:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 14:41 [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes David Sterba
2021-10-18 14:47 ` [PATCH RFC] btrfs-progs: send protocol v2 stub, UTIMES2, OTIME David Sterba
2021-10-18 21:42   ` Omar Sandoval
2021-10-19 12:53     ` David Sterba
2021-10-19 14:11       ` Josef Bacik
2021-10-19 17:27       ` Omar Sandoval
2021-10-18 15:36 ` [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes Filipe Manana
2021-10-18 21:26 ` Omar Sandoval
2021-10-19 10:51   ` David Sterba [this message]
2021-10-19  7:30 ` Nikolay Borisov
2021-10-19 17:38 ` Omar Sandoval
2021-10-19 20:25   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211019105133.GQ30611@suse.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox