On Tue, Jun 5, 2012 at 12:16 PM, Alexander Block <abloc...@googlemail.com> wrote: > 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.
Thanks for the update, Alex. Efficiently comparing the trees is the crux of what we were looking into. Thanks, 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
