On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas <alex.bolshoy.bt...@gmail.com> wrote: > > Yes, I also noticed that sometimes transid gets bumped up, but there > is no actual change. > > So let's say you identify that a particular part of the tree is not > shared anymore, and, say, eventually you get to a particular leaf > within that part of the tree. How would you detect that, say, a > particular INODE_ITEM (or, more difficult, an INODE_REF) is missing > from that leaf WRT to previous tree? > > The property you described perhaps suggests another method to find > leafs, in which *something* has changed. (Although within a leaf, does > it make sense to decode all items and to look at their transid - those > that have them - to filter out even more?) And yes, perhaps, looking > at transid alone will bring more such potential leafs into > consideration. > > However, how does this property help to determine *what* actually has > changed between the two trees? Like, for example, being able to tell > over which range of keys there possibly was a change, and iterate > within that range? When doing incremental sends, we always have two trees at hand. One where we know that it is already on the receiving side (we did already send it) and the one that we want to send now. To find the changes, we simply compare those trees. If an items misses on one tree, we know it's either new or deleted (depending on the tree the item lies in).
I would suggest you to not put too much work into send. As already said, the btrfs send/receive patches are close to be posted to the mailing list. It's currently reviewed and when I get a "looks good now", I'll post it. > > Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
