Re: [PATCH RFC] btrfs-progs: send protocol v2 stub, UTIMES2, OTIME

[David Sterba <dsterba@suse.cz>]

On Mon, Oct 18, 2021 at 02:42:34PM -0700, Omar Sandoval wrote:
> On Mon, Oct 18, 2021 at 04:47:17PM +0200, David Sterba wrote:
> > +	int ret;
> > +	struct btrfs_receive *rctx = user;
> > +	char full_path[PATH_MAX];
> > +
> > +	ret = path_cat_out(full_path, rctx->full_subvol_path, path);
> > +	if (ret < 0) {
> > +		error("otime: path invalid: %s", path);
> > +		goto out;
> > +	}
> > +
> > +	if (bconf.verbose >= 3) {
> > +		char ot_str[128];
> > +
> > +		if (sprintf_timespec(ot, ot_str, sizeof(ot_str) - 1) < 0)
> > +			goto out;
> > +		fprintf(stderr, "otime %s\n", ot_str);
> > +	}
> > +
> > +out:
> > +	return 0;
> > +}
> 
> Are you planning to do anything with otime (e.g., storing it in an
> xattr) in the future?

At this point I don't have further plan to use the value on the receive
side, there's no standard way to track otime outside of the inode. This
is up to the application, it can be stored in a xattr or just
cross-referenced with some other data.

I don't remember if there was a specific request for the otime in the
protocol, but for completeness of the information it makes sense to
transfer it to the receiving side.

> >  static const char * const cmd_send_usage[] = {
> >  	"btrfs send [-ve] [-p <parent>] [-c <clone-src>] [-f <outfile>] <subvol> [<subvol>...]",
> >  	"Send the subvolume(s) to stdout.",
> > @@ -447,6 +483,7 @@ static const char * const cmd_send_usage[] = {
> >  	"                 does not contain any file data and thus cannot be used",
> >  	"                 to transfer changes. This mode is faster and useful to",
> >  	"                 show the differences in metadata.",
> > +	"--proto N        request maximum protocol version N (default: highest supported by running kernel)",
> 
> Can we default to version 1 and provide a way to opt in to the latest
> version? I'm concerned with a kernel upgrade suddenly creating a send
> stream that the receiving side can't handle. Making this opt-in rather
> than opt-out seems safer.

Default to v1 is safe, but what's your idea when to change it?

The send/receive usecase has 4 moving parts, kernel/send, progs/send,
progs/receive, kernel/receive. On different hosts and both parts
happening at potentially different times. Getting out of that with sane
defaults will be fun.

I agree that bumping the default any time kernel with new protocol
version support can break things quite easily, so that's against the
usability principles.

As the default is in progs it's a bit more flexible as it does not
require kernel update/reboot. The maximum supported value is known and
the 'default' value 0 for proto version allows that in a way that does
not require updating scripts.

So for first public release, I'll keep the default 1. Changes in the
default version can follow a similar way like mkfs, ie. when there's a
sufficient support in stable kernels. We'll probably also gather some
feedback over time so can decide accordingly.