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:

quoted

On Mon, Oct 18, 2021 at 04:47:17PM +0200, David Sterba wrote:

quoted

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

quoted

quoted

 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