On 25/10/2021 07:48, Nikolay Borisov wrote:

On 22.10.21 г. 17:53, David Sterba wrote:

quoted

This is the infrastructure part only, without any new updates, thus safe
to be applied now and all other changes built on top of it, unless there
are further comments.

---

This is preparatory work for send protocol update to version 2 and
higher.

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.

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.

The version is still unchanged and will be increased once we have new
incompatible commands or stream updates.

Signed-off-by: David Sterba <dsterba@suse.com>

Reviewed-by: Nikolay Borisov <redacted>

I have a question about how this will work from the point of view of the
sysadmin.

I have a number of different systems between which I need send and
receive working. Some are stable machines - many using distro stable
kernels. Some are new machines (most running debian testing but
occasionally with a newer kernel for some other reason). Some are
managed by other people and I don't control the kernel or progs versions
or am even told when they change.

I need to be able to generate a send stream on any system and receive it
on any other system. However, I don't want to be limited to just the
very oldest version of the protocol: for some tasks I am willing to take
into account the target system capabilities when generating a send
stream for that task.

So, I think what I need is:

1) A mechanism to query a receiving system to find out what protocol
range it supports for receive (taking into account *both* kernel and
btrfs-receive capabilities). And when I say "protocol version" I mean
feature level - the reported "version" must define not just encodings
but also what capabilities it can handle.

2) A mechanism to select what protocol version (in the sense above)
btrfs-send should use in the stream (again, kernel and user space).

3) **Preferably** filesystem features on the sending side which require
protocol features outside the selected range would be emulated using
features in the earlier protocols. If that cannot be done,
**definitely** abort the send and report an error. If the send completes
without error the stream must be within the specified protocol range and
work on a receiver which claims to support that range.

That way, I can check which version the receiver supports (maybe in a
script in real time or maybe as a config option I change when necessary)
and generate a send stream which it can use. And if I can't do that, I
get a clear error. I would also be able to request tools like btrbk to
use this information when taking snapshot backups.

I am not sure I can do that with the mechanisms being proposed here. Am
I missing something?

Graham