Re: [PATCH 1/4] Btrfs: send, bump stream version

[Mark Fasheh <mfasheh@suse.de>]

On Tue, Apr 15, 2014 at 06:57:17PM +0100, Filipe David Manana wrote:
> >> > Are these changes compatible with software using the old stream version? We
> >> > have snapshotting tools that are using send/recieve and it would be bad to
> >> > change the ABI in incompatible ways underneath them.
> >> >         --Mark
> >>
> >> New versions of btrfs-progs (send stream v2 support) will still be
> >> able to read and process v1 streams. Older btrfs-progs (v1 only) won't
> >> be able to process the new commands.
> >> Does this answers your question Mark?
> >
> > Yes it does thanks. Unfortunately though this is unacceptable behavior -
> > kernel upgrades are not supposed to break existing userspace interfaces.
> >
> > In particular what will happen here is that the user will grab a new kernel
> > and then find out that their fancy snapshotting software won't work any
> > more.
> 
> Good point. I followed this approach based on Josef's comments on a
> previous rfc at http://www.spinics.net/lists/linux-btrfs/msg32999.html

Apparently Josef doesn't get those sorts of bugs in his queue ;)


> The only alternative I can think of right now is to use new send ioctl
> flags instead, so that new clients able to process the new commands
> will pass these flags explicitly, while old clients would continue to
> work without changes (and not bumping the stream version, as
> btrfs-receive refuses versions higher than 1 currently). This seems to
> be similar to what was done here:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=cb95e7bf7ba481c3d35b238b1cd671b63f54238a

Yeah that works for me - any client that understand the new features just
sends some flag that indicates it can process them. Then we know that old
clients will continue to work unaffected.

Thanks Filipe,
	--Mark

--
Mark Fasheh