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

[Josef Bacik <josef@toxicpanda.com>]

On Tue, Oct 19, 2021 at 02:53:59PM +0200, David Sterba wrote:
> 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.

It's waaaaaaay easier to go "oh shit, I need a new btrfs-progs" than "oh shit, I
need a new kernel."  I think that having the kernel generate new send streams is
reasonable, because distro's are more likely to lag behind on kernels than
userspace.  If we have users on the cutting edge they're likely to be on the
cutting edge in both cases.  And if they get a sendstream that doesn't apply we
have a nice (at least I hope) message that says "this send stream is too new,
try a newer btrfs-progs", so it's an easy remedy.  Thanks,

Josef