Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org, nborisov@suse.com
Subject: Re: [PATCH RFC] btrfs: send: v2 protocol and example OTIME changes
Date: Mon, 18 Oct 2021 14:26:56 -0700	[thread overview]
Message-ID: <YW3moPgbBMQhN7XY@relinquished.localdomain> (raw)
In-Reply-To: <20211018144109.18442-1-dsterba@suse.com>

On Mon, Oct 18, 2021 at 04:41:09PM +0200, David Sterba wrote:
> This is send protocol update to version 2 with example new commands.
> 
> We have many pending protocol update requests but still don't have the
> basic protocol rev in place, the first thing that must happen is to do
> the actual versioning support. In order to have something to test,
> there's an extended and a new command, that should be otherwise harmless
> and nobody should depend on it. This should be enough to validate the
> non-protocol changes and backward compatibility before we do the big
> protocol update.
> 
> The protocol version is u32 and is a new member in the send ioctl
> struct. Validity of the version field is backed by a new flag bit. Old
> kernels would fail when a higher version is requested. Version protocol
> 0 will pick the highest supported version, BTRFS_SEND_STREAM_VERSION,
> that's also exported in sysfs.
> 
> Protocol changes:
> 
> - new command BTRFS_SEND_C_UTIMES2
> - appends OTIME after the output of BTRFS_SEND_C_UTIMES
> - this is an example how to extend an existing command based on protocol
>   version
> 
> - new command BTRFS_SEND_C_OTIME
> - path BTRFS_SEND_A_PATH
> - timespec attribute BTRFS_SEND_A_OTIME
> - it's a separate command so it does not bloat any UTIMES2 commands,
>   and is emitted only after inode creation (file, dir, special files).
> 
> The patch should be a template for further protocol extensions
> 
> RFC:
> 
> - 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.

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?

  parent reply	other threads:[~2021-10-18 21:27 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 [this message]
2021-10-19 10:51   ` David Sterba
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=YW3moPgbBMQhN7XY@relinquished.localdomain \
    --to=osandov@osandov.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.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