23.03.2016 02:28, Chris Murphy пишет:
On Mon, Mar 21, 2016 at 1:29 PM, Andrei Borzenkov
wrote: 19.03.2016 21:35, Chris Murphy пишет:
On Fri, Mar 18, 2016 at 11:32 PM, Andrei Borzenkov
wrote: 19.03.2016 04:00, Chris Murphy пишет:
On Fri, Mar 18, 2016 at 3:51 AM, Andrei Borzenkov
wrote: On Fri, Mar 18, 2016 at 2:39 AM, Chris Murphy
wrote: ... > > I have two subvolumes, root and home. I used to do separate boot, I > don't anymore. Simple version is this: > > cd /boot > tar -acf bootefi.tar.gz efi/ > mount -o subvolid=5 /dev/sdX /mnt > cd /mnt > btrfs sub snap -r root root.6 > btrfs sub snap -r home home.6 > btrfs send -p root.5 root.6 | ssh chris@ip 'btrfs receive /backups' > btrfs send -p home.5 home.6 | ssh chris@ip 'btrfs receive /backups' > Do you need to create subvolumes on destination in advance or are they created automatically by btrfs receive?
They're created by receive. The very first send is different, it omits -p because it's not an incremental send. And with -p option on the send side, the receive side must already have that subvolume.
How does it verify that baseline snapshot is really unchanged? Using name only? I.e. if I rename completely unrelated subvolume as home.5 on destination, will it apply diff between source home.5 and home.6?
Only read-only snapshots can be sent received. Hence the -r when the snapshot is taken. I haven't looked at the code, but I expect names are only used by user space, where the subvol uuids are used behind the scene: each subvolume has its own uuid, a parent uuid, and a received uuid to keep track of relationships on and across volumes.
Like I mentioned in the example, home.5 must already be on the destination to incrementally send home.6. How do you rename an unrelated subvolume to match an existing subvolume name?
mv /home.5 /some-other-name mv /unrelated-subvolume /home.5
That would fail.
Why?
home.5 is a read only subvolume, it can't be renamed, which also means it can't be moved either.
Of course it can. Did you actually try it? I did before posting :) "Read-only" here refers to subvolume content, not to its "attachment point".
Only read-only subvolumes (snapshots) can be sent/received. And they can't be modified on either side or you mess up the integrity of the whole thing. If you want to make a derivative for modification you need to make a snapshot of that without -r, so that it's a read write snapshot then you can do whatever you want with it.
And even if it succeeded, the "fake" home.5 would not have the same parent uuid or received uuid as what's expected when using -p on the send side.
How send side knows what parent uuid to expect on receive side in the first place? This information should be kept somewhere. How can I see what parent uuid is expected for next operation?
It's the receive side that expects this information to match because it's the receive side's job to effectively snapshot the parent already on the receive side, then modified that snapshot with the incremental send stream.
Well, how does *receive* side know what snapshot on send side to expect then? Again - all that sounds like the only thing receive side knows is subvolume name and subvolume name can be changed arbitrarily.
Not that I really understand what "parent" in case of btrfs means ...
So the receive would fail.
Yes and since it's an early check, it somehow backfires and fails send also, so it's not like you end up with a hung send process that keeps sending stuff that can't be received.
Here's a "simplified version" where I've tacked on a single letter after each unique UUID.
This is the "send" side:
Name: original UUID: 9e7736a6-ad72-4f43-b7c9-fc4bf73bf74b A Parent UUID: - Received UUID: -
Name: original.snapshot UUID: 80134f6c-8dda-df48-9e00-af0213bc1234 B Parent UUID: 9e7736a6-ad72-4f43-b7c9-fc4bf73bf74b A Received UUID: -
Name: originalmodified.snapshot UUID: c2aa5bac-bb3a-8641-89c8-5d6da2b810d2 C Parent UUID: 9e7736a6-ad72-4f43-b7c9-fc4bf73bf74b A Received UUID: -
================ This is the "receive" side
Name: original.snapshot UUID: bceda471-de5c-6d42-afa0-72ec47080625 D Parent UUID: - Received UUID: 80134f6c-8dda-df48-9e00-af0213bc1234 B
Name: originalmodified.snapshot UUID: 29f83d8c-79f0-9f4f-b5bc-ff4fb4effb87 E Parent UUID: bceda471-de5c-6d42-afa0-72ec47080625 D Received UUID: c2aa5bac-bb3a-8641-89c8-5d6da2b810d2 C
Is received UUID actually present on receive side somewhere after "btrfs send | btrfs receive" has completed?
The receive was populated from the send side using commands: [root@f23s ~]# btrfs send original.snapshot | ssh root@10.0.0.4 'btrfs receive /root/'
[root@f23s ~]# btrfs send -p original.snapshot originalmodified.snapshot/ | ssh root@10.0.0.4 'btrfs receive /root/'
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org