On 08/25/12 14:23, Alexander Block wrote: > On Fri, Aug 24, 2012 at 4:15 PM, Jeff Liu <jeff.liu@xxxxxxxxxx> wrote: >> Hi Alex, >> >> Thanks for taking a look. >> >> On 08/24/2012 09:09 PM, Alex Lyakas wrote: >> >>> Hi Jeff, >>> how do you see this snapshot-diff functionality vs the send/receive >>> functionality that was recently added? I think that the binary stream >>> that the send code produces, can be interpreted by printing out text >>> messages, which will essentially give the same information (although >>> much more detailed) as your snapshot-diff tool. >> send/receive has not yet implemented when I working on this feature(back to the end of last year). >> looks there really has some duplicate efforts. >> >> Just as you said, the produced stream of send need to interpret to show readable info, if the binary stream is >> became huge enough, maybe that will make some silly user crying like me :). >> Also, it is mainly focus on backup purpose IMHO, please correct me if I missing something in this point. >> >> The diff utility is designed to list any changes between two snapshots in a straightforward way consider the command interface, >> it also can be improved to show the differences at a given time range. >> >> But sure, send/receive is just awesome, if we can introduce a interpreted script which do same thing to >> make end user's life easier, that would be fine. >> >> Thanks, >> -Jeff >> >>> Apologies if I somehow misunderstood what your snapshot-diff code does. >>> >>> Thanks, >>> Alex. >>> >>> >>> On Tue, Aug 7, 2012 at 11:56 AM, Jeff Liu <jeff.liu@xxxxxxxxxx> wrote: >>>> Hello, >>>> >>>> I've done a prototype implementation of snapshot diff utility many months ago. >>>> It was originally meant to analyze the differences between two snapshots which are >>>> inherited from the same subvolume/snapshot. >>>> My idea was to introduce new "instructions" to the stream later which >>>> could be activated using a flag in the ioctl structure. These >>>> instructions would not be real instruction but diff statements. They >>>> would contain the plain results as given by btrfs_compare_trees. So we >>>> would have the information which tree items were >>>> added/removed/changed. As an alternative, this could be a new ioctl. Sound interesting. The performance of interpret huge streams from the user land could resolved in this way, am looking forward to see that become true so. :) Thanks, -Jeff > > Greetings from Ko Tao :) > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
