btrfs receive incremental stream on another uuid

btrfs receive incremental stream on another uuid

[Gervais, Francois]

Hi,

I'm trying to apply a btrfs send diff (done through -p) to another subvolume with the same content as the proper parent but with a different uuid.

I looked through btrfs receive and I get the feeling that this is not possible right now.

I'm thinking of adding a -p option to btrfs receive which could override the parent information from the stream.

Would that make sense?

Re: btrfs receive incremental stream on another uuid

[Andrei Borzenkov]

18.09.2018 20:56, Gervais, Francois пишет:
> 
> Hi,
> 
> I'm trying to apply a btrfs send diff (done through -p) to another subvolume with the same content as the proper parent but with a different uuid.
> 
> I looked through btrfs receive and I get the feeling that this is not possible right now.
> 
> I'm thinking of adding a -p option to btrfs receive which could override the parent information from the stream.
> 
> Would that make sense?
> 
No. It is already possible (by setting received UUID); it should not be
made too open to easy abuse.

Re: btrfs receive incremental stream on another uuid

[Gervais, Francois]

> No. It is already possible (by setting received UUID); it should not be
made too open to easy abuse.


Do you mean edit the UUID in the byte stream before btrfs receive?

Re: btrfs receive incremental stream on another uuid

[Andrei Borzenkov]

18.09.2018 21:28, Gervais, Francois пишет:
>> No. It is already possible (by setting received UUID); it should not be
> made too open to easy abuse.
> 
> 
> Do you mean edit the UUID in the byte stream before btrfs receive?
> 
No, I mean setting received UUID on subvolume. Unfortunately, it is
possible. Fortunately, it is not trivially done.

Re: btrfs receive incremental stream on another uuid

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Tue, Sep 18, 2018 at 06:28:37PM +0000, Gervais, Francois wrote:
> > No. It is already possible (by setting received UUID); it should not be
> made too open to easy abuse.
> 
> 
> Do you mean edit the UUID in the byte stream before btrfs receive?

   No, there's an ioctl to change the received UUID of a
subvolume. It's used by receive, at the very end of the receive
operation.

   Messing around in this area is basically a recipe for ending up
with a half-completed send/receive full of broken data because the
receiving subvolume isn't quite as identical as you thought. It
enforces the rules for a reason.

   Now, it's possible to modify the send stream and the logic around
it a bit to support a number of additional modes of operation
(bidirectional send, for example), but that's queued up waiting for
(a) a definitive list of send stream format changes, and (b) David's
bandwidth to put them together in one patch set.

   If you want to see more on the underlying UUID model, and how it
could be (ab)used and modified, there's a write-up here, in a thread
on pretty much exactly the same proposal that you've just made:

https://www.spinics.net/lists/linux-btrfs/msg44089.html

   Hugo.

-- 
Hugo Mills             | Great films about cricket: Monster's No-Ball
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]