From: Jie Liu <jeff.liu@oracle.com>
To: Alexander Block <ablock84@googlemail.com>
Cc: Alex Lyakas <alex.bolshoy.btrfs@gmail.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH 0/5] btrfs-progs: snapshot diff function
Date: Sun, 26 Aug 2012 20:26:04 +0800 [thread overview]
Message-ID: <503A15DC.3000902@oracle.com> (raw)
In-Reply-To: <CAB9VWqCHdh_-TSPovszJVCz4R2s8B6zOjA5mJ87Q=xKB+sKZPQ@mail.gmail.com>
On 08/25/12 14:23, Alexander Block wrote:
> On Fri, Aug 24, 2012 at 4:15 PM, Jeff Liu <jeff.liu@oracle.com> 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@oracle.com> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-08-26 12:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 8:56 [RFC PATCH 0/5] btrfs-progs: snapshot diff function Jeff Liu
2012-08-07 8:57 ` [RFC PATCH 1/5] btrfs-progs: make ino_resovle() shared Jeff Liu
2012-08-07 8:57 ` [RFC PATCH 2/5] btrfs-progs: header file of snapshot diff Jeff Liu
2012-08-07 8:57 ` [RFC PATCH 3/5] btrfs-progs: souce " Jeff Liu
2012-08-07 8:57 ` [RFC PATCH 4/5] btrfs-progs: teach Makefile aware of the new comer Jeff Liu
2012-08-07 8:58 ` [RFC PATCH 5/5] btrfs-progs: let this feature works at subvolume command group Jeff Liu
2012-08-24 13:09 ` [RFC PATCH 0/5] btrfs-progs: snapshot diff function Alex Lyakas
2012-08-24 14:15 ` Jeff Liu
2012-08-25 6:23 ` Alexander Block
2012-08-26 12:26 ` Jie Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=503A15DC.3000902@oracle.com \
--to=jeff.liu@oracle.com \
--cc=ablock84@googlemail.com \
--cc=alex.bolshoy.btrfs@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).