On Mon, Mar 21, 2016 at 1:29 PM, Andrei Borzenkov
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. 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.
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 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/' -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org