On 08/25/12 14:23, Alexander Block wrote:

On Fri, Aug 24, 2012 at 4:15 PM, Jeff Liu [off-list ref] wrote:

quoted

Hi Alex,

Thanks for taking a look.

On 08/24/2012 09:09 PM, Alex Lyakas wrote:

quoted

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

quoted

Apologies if I somehow misunderstood what your snapshot-diff code does.

Thanks,
Alex.


On Tue, Aug 7, 2012 at 11:56 AM, Jeff Liu [off-list ref] wrote:

quoted

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.

quoted

quoted

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html