On Thu, Jun 11, 2015 at 01:16:26PM -0400, Josef Bacik wrote: > On 06/11/2015 01:09 PM, Hugo Mills wrote: > >On Thu, Jun 04, 2015 at 05:17:25PM -0400, Josef Bacik wrote: > >>Neil Horman pointed out a problem where if he did something like this > >> > >>receive A > >>snap A B > >>change B > >>send -p A B > >> > >>and then on another box do > >> > >>recieve A > >>receive B > >> > >>the receive B would fail because we use the UUID of A for the clone sources for > >>B. This makes sense most of the time because normally you are sending from the > >>original sources, not a received source. However when you use a recieved subvol > >>its UUID is going to be something completely different, so if you then try to > >>receive the diff on a different volume it won't find the UUID because the new A > >>will be something else. The only constant is the received uuid. So instead > >>check to see if we have received_uuid set on the root, and if so use that as the > >>clone source, as btrfs receive looks for matches either in received_uuid or > >>uuid. Thanks, > > > > While this deals with Neil's problem, there's a few other use-cases > >that people have been asking for that (I think) it won't deal with. > > > > I think ultimately we should be sending all three of the parent > >UUID, the parent's Received UUID (if it exists), and the parent's > >Parent UUID. That would have to go in the FARv2 update, though. > > > > However, since this patch doesn't rule out the above happening at > >some future date, and I think it'll do the job as described above, > > > > Yeah I'd like to send more information so we can better find the > UUID we're looking for, but I think at least trying to keep a > consistent UUID we carry around would be good. Received UUID mostly > accomplishes this, I'd like to know what other use cases aren't > working so we can think about what we need to do for them. Thanks, I did a write-up of this a while ago, in some detail (which is why I weighed in here): http://www.spinics.net/lists/linux-btrfs/msg44089.html I'm afraid it's rather long, but the tl;dr is the second indented section in "What to do about it", with the notation described in detail in the first few paragraphs. Hugo. -- Hugo Mills | ... one ping(1) to rule them all, and in the hugo@... carfax.org.uk | darkness bind(2) them. http://carfax.org.uk/ | PGP: E2AB1DE4 | Illiad
Attachment:
signature.asc
Description: Digital signature
