Btrfs devel - Oct 2012 - find-new possibility of showing modified and deleted files/directories

Currently find-new only shows certain operations and probably for a great
reason.

I''m trying to use find-new to preseed a file list to rsync so that I
don''t
have to traverse incredibly large directory trees.

Unfortunately find-new doesn''t show deletion and a few other
modifications.

I''m very tempted to use snapshots and decode a transfer log to get at
this
information since that seems the most supportable way of doing this at the
moment.

Is it possible to enable all file modification types into the results of
find-new including unlink?

- Shane
--
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

That''s Plan B.  I''ll be making a btrfs stream decoder and
doing in
place edits.  I need to move stuff around to other filesystem types
otherwise I''d just store the stream or apply the stream to a remote
snapshot.

On Wed, Oct 31, 2012 at 4:13 PM, cwillu <cwillu@gmail.com>
wrote:
> Probably easier to decode the btrfs-send stream, or even just use
btrfs-send
> itself instead.
--
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

On 11/01/2012 02:28 AM, Shane Spencer wrote:
> That''s Plan B.  I''ll be making a btrfs stream decoder and
doing in
> place edits.  I need to move stuff around to other filesystem types
> otherwise I''d just store the stream or apply the stream to a
remote
> snapshot.
That''s the whole point of the btrfs-send design: It''s very
easy to
receive on different filesystems. A generic receiver is in preparation.
And to make it even more generic: A sender using the same stream
format is also in preparation for zfs.
> 
> On Wed, Oct 31, 2012 at 4:13 PM, cwillu <cwillu@gmail.com> wrote:
>> Probably easier to decode the btrfs-send stream, or even just use
btrfs-send
>> itself instead.
> --
> 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
> 
--
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

On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>> That''s Plan B.  I''ll be making a btrfs stream decoder
and doing in
>> place edits.  I need to move stuff around to other filesystem types
>> otherwise I''d just store the stream or apply the stream to a
remote
>> snapshot.
> That''s the whole point of the btrfs-send design: It''s
very easy to
> receive on different filesystems. A generic receiver is in preparation.
> And to make it even more generic: A sender using the same stream format
> is also in preparation for zfs.
Consider the rsync bundle format as well.
That should provide interoperability with any filesystem.

--
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

On 01.11.2012 12:00, Gabriel wrote:
> On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
>> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>>> That''s Plan B.  I''ll be making a btrfs stream
decoder and doing in
>>> place edits.  I need to move stuff around to other filesystem types
>>> otherwise I''d just store the stream or apply the stream to
a remote
>>> snapshot.
> 
>> That''s the whole point of the btrfs-send design: It''s
very easy to
>> receive on different filesystems. A generic receiver is in preparation.
>> And to make it even more generic: A sender using the same stream format
>> is also in preparation for zfs.
> 
> Consider the rsync bundle format as well.
> That should provide interoperability with any filesystem.
Rsync is an interactive protocol. The idea with send/receive is that
the stream can be generated without any interactions with receiver.
You can store the stream somewhere, or replay it to many destinations.
> 
> --
> 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
--
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

On Thu, 01 Nov 2012 12:29:36 +0100, Arne Jansen wrote:
> On 01.11.2012 12:00, Gabriel wrote:
>> On Thu, 01 Nov 2012 06:06:57 +0100, Arne Jansen wrote:
>>> On 11/01/2012 02:28 AM, Shane Spencer wrote:
>>>> That''s Plan B.  I''ll be making a btrfs stream
decoder and doing in
>>>> place edits.  I need to move stuff around to other filesystem
types
>>>> otherwise I''d just store the stream or apply the
stream to a remote
>>>> snapshot.
>> 
>>> That''s the whole point of the btrfs-send design:
It''s very easy to
>>> receive on different filesystems. A generic receiver is in
>>> preparation.
>>> And to make it even more generic: A sender using the same stream
>>> format is also in preparation for zfs.
>> 
>> Consider the rsync bundle format as well.
>> That should provide interoperability with any filesystem.
> 
> Rsync is an interactive protocol. The idea with send/receive is that the
> stream can be generated without any interactions with receiver. You can
> store the stream somewhere, or replay it to many destinations.
Same with rsync''s batch mode. Here is more about it:

http://manpages.ubuntu.com/manpages/precise/man1/rsync.1.html#contenttoc21


--
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

On Wed, Oct 31, 2012 at 9:06 PM, Arne Jansen <sensille@gmx.net>
wrote:
>
> On 11/01/2012 02:28 AM, Shane Spencer wrote:
> > That''s Plan B.  I''ll be making a btrfs stream
decoder and doing in
> > place edits.  I need to move stuff around to other filesystem types
> > otherwise I''d just store the stream or apply the stream to a
remote
> > snapshot.
>
> That''s the whole point of the btrfs-send design: It''s
very easy to
> receive on different filesystems. A generic receiver is in preparation.
> And to make it even more generic: A sender using the same stream
> format is also in preparation for zfs.
>
You just made my day. I will probably be approaching a lot of this
from Python as well so I''m very interested in the stream format
itself.
--
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