Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Alexander Block
On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen sensi...@gmx.net wrote:
 On 04.07.2012 15:39, Alexander Block wrote:
 Hello all,

 This is the user space side of btrfs send/receive.

 You can apply them manually or use my git repo:

 git://github.com/ablock84/btrfs-progs.git (branch send)

 The branch is based on Hugo's integration-20120605 branch. I had to add a 
 temporary
 commit to fix a bug introduced in one of the strncpy/overflow patches that 
 got into
 btrfs-progs. This fix is not part of the btrfs send/receive patchset, but 
 you'll
 probably need it if you want to base on the integration branch. I hope this 
 is not
 required in the future when a new integration branch comes out.

 Example usage:

 Multiple snapshots at once:
 btrfs send /mnt/snap[123]  snap123.btrfs

 a) Do we really want a single token command here, not
 btrfs filesystem send or subvol send?
In my opinion the single token is easier to type and remember. But if
enough speaks for normal subcommands this can be changed (but by
someone else as I'm running out of time).
 b) zfs makes sure stdout is not a tty, to prevent flooding
 your console. This kinda makes sense.
This makes sense. But again, this has to be done by someone else.


 Single snapshot with manual parent:
 btrfs send -p /mnt/snap3 /mnt/snap4  snap4.btrfs

 Receive both streams:
 btrfs receive /mnt2  snap123.btrfs
 btrfs receive /mnt2  snap4.btrfs

 (Please give suggestions for a file extension)

 Please read the kernel side email as well, especially the warnings!

 Alex.

 Alexander Block (6):
   Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h
   Btrfs-progs: update ioctl.h to support clone range ioctl
   Btrfs-progs: print inode transid and dir item data field in
 debug-tree
   Btrfs-progs: update btrfs-progs for subvol uuid+times support
   Btrfs-progs: update ioctl.h to support btrfs send ioctl
   Btrfs-progs: add btrfs send/receive commands

  Makefile   |7 +-
  btrfs.c|2 +
  cmds-receive.c |  910 
 
  cmds-send.c|  677 +
  commands.h |4 +
  ctree.h|   40 ++-
  ioctl.h|   35 ++-
  print-tree.c   |   88 --
  send-stream.c  |  480 ++
  send-stream.h  |   58 
  send-utils.c   |  337 +
  send-utils.h   |   69 +
  send.h |  132 
  13 files changed, 2815 insertions(+), 24 deletions(-)
  create mode 100644 cmds-receive.c
  create mode 100644 cmds-send.c
  create mode 100644 send-stream.c
  create mode 100644 send-stream.h
  create mode 100644 send-utils.c
  create mode 100644 send-utils.h
  create mode 100644 send.h


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


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Hugo Mills
On Wed, Jul 25, 2012 at 12:41:56PM +0200, Alexander Block wrote:
 On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen sensi...@gmx.net wrote:
  On 04.07.2012 15:39, Alexander Block wrote:
  Hello all,
 
  This is the user space side of btrfs send/receive.
 
  You can apply them manually or use my git repo:
 
  git://github.com/ablock84/btrfs-progs.git (branch send)
 
  The branch is based on Hugo's integration-20120605 branch. I had to add a 
  temporary
  commit to fix a bug introduced in one of the strncpy/overflow patches that 
  got into
  btrfs-progs. This fix is not part of the btrfs send/receive patchset, but 
  you'll
  probably need it if you want to base on the integration branch. I hope 
  this is not
  required in the future when a new integration branch comes out.
 
  Example usage:
 
  Multiple snapshots at once:
  btrfs send /mnt/snap[123]  snap123.btrfs
 
  a) Do we really want a single token command here, not
  btrfs filesystem send or subvol send?
 In my opinion the single token is easier to type and remember. But if
 enough speaks for normal subcommands this can be changed (but by
 someone else as I'm running out of time).

   Since everything else is two commands, yes, I think we need it for
consistency. (And, since it's a publically-visible interface, for
acceptance of the patches -- we don't want to be changing the way the
commands work after the fact).

  b) zfs makes sure stdout is not a tty, to prevent flooding
  your console. This kinda makes sense.
 This makes sense. But again, this has to be done by someone else.

   Can you keep a brief list of such cleanups/features and dump it on
the wiki as a proposed project when your time does run out, please.
That way the details don't get lost, and they can be found by other
people and dealt with independently.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Turning,  pages turning in the widening bath, / The spine ---
cannot bear the humidity. / Books fall apart; the binding
cannot hold. / Page 129 is loosed upon the world.


signature.asc
Description: Digital signature


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Chris Mason
On Wed, Jul 25, 2012 at 08:00:36AM -0600, Hugo Mills wrote:
 On Wed, Jul 25, 2012 at 12:41:56PM +0200, Alexander Block wrote:
  On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen sensi...@gmx.net wrote:
   On 04.07.2012 15:39, Alexander Block wrote:
   Hello all,
  
   This is the user space side of btrfs send/receive.
  
   You can apply them manually or use my git repo:
  
   git://github.com/ablock84/btrfs-progs.git (branch send)
  
   The branch is based on Hugo's integration-20120605 branch. I had to add 
   a temporary
   commit to fix a bug introduced in one of the strncpy/overflow patches 
   that got into
   btrfs-progs. This fix is not part of the btrfs send/receive patchset, 
   but you'll
   probably need it if you want to base on the integration branch. I hope 
   this is not
   required in the future when a new integration branch comes out.
  
   Example usage:
  
   Multiple snapshots at once:
   btrfs send /mnt/snap[123]  snap123.btrfs
  
   a) Do we really want a single token command here, not
   btrfs filesystem send or subvol send?
  In my opinion the single token is easier to type and remember. But if
  enough speaks for normal subcommands this can be changed (but by
  someone else as I'm running out of time).
 
Since everything else is two commands, yes, I think we need it for
 consistency. (And, since it's a publically-visible interface, for
 acceptance of the patches -- we don't want to be changing the way the
 commands work after the fact).

I've been sending and receiving while getting this code integrated.
These are really first class operations, and I'd prefer they not be
sub-commands.

I'm afraid there isn't a lot of logic here, just what feels good to
type.

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


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Alexander Block
On Wed, Jul 25, 2012 at 4:00 PM, Hugo Mills h...@carfax.org.uk wrote:
 On Wed, Jul 25, 2012 at 12:41:56PM +0200, Alexander Block wrote:
 On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen sensi...@gmx.net wrote:
  On 04.07.2012 15:39, Alexander Block wrote:
  Hello all,
 
  This is the user space side of btrfs send/receive.
 
  You can apply them manually or use my git repo:
 
  git://github.com/ablock84/btrfs-progs.git (branch send)
 
  The branch is based on Hugo's integration-20120605 branch. I had to add a 
  temporary
  commit to fix a bug introduced in one of the strncpy/overflow patches 
  that got into
  btrfs-progs. This fix is not part of the btrfs send/receive patchset, but 
  you'll
  probably need it if you want to base on the integration branch. I hope 
  this is not
  required in the future when a new integration branch comes out.
 
  Example usage:
 
  Multiple snapshots at once:
  btrfs send /mnt/snap[123]  snap123.btrfs
 
  a) Do we really want a single token command here, not
  btrfs filesystem send or subvol send?
 In my opinion the single token is easier to type and remember. But if
 enough speaks for normal subcommands this can be changed (but by
 someone else as I'm running out of time).

Since everything else is two commands, yes, I think we need it for
 consistency. (And, since it's a publically-visible interface, for
 acceptance of the patches -- we don't want to be changing the way the
 commands work after the fact).

  b) zfs makes sure stdout is not a tty, to prevent flooding
  your console. This kinda makes sense.
 This makes sense. But again, this has to be done by someone else.

Can you keep a brief list of such cleanups/features and dump it on
 the wiki as a proposed project when your time does run out, please.
 That way the details don't get lost, and they can be found by other
 people and dealt with independently.
Added a page to the wiki:
https://btrfs.wiki.kernel.org/index.php/Btrfs_Send/Receive

Hugo.

 --
 === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
   PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
 --- Turning,  pages turning in the widening bath, / The spine ---
 cannot bear the humidity. / Books fall apart; the binding
 cannot hold. / Page 129 is loosed upon the world.
--
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


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Alex Lyakas
Alexander,
can you pls let know like a day or two before you run out of time?
I have compiled a list of questions, but also want to do more testing
before I publish them all.

Thanks for your work,
Alex.

On Wed, Jul 25, 2012 at 7:56 PM, Alexander Block
abloc...@googlemail.com wrote:
 On Wed, Jul 25, 2012 at 4:00 PM, Hugo Mills h...@carfax.org.uk wrote:
 On Wed, Jul 25, 2012 at 12:41:56PM +0200, Alexander Block wrote:
 On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen sensi...@gmx.net wrote:
  On 04.07.2012 15:39, Alexander Block wrote:
  Hello all,
 
  This is the user space side of btrfs send/receive.
 
  You can apply them manually or use my git repo:
 
  git://github.com/ablock84/btrfs-progs.git (branch send)
 
  The branch is based on Hugo's integration-20120605 branch. I had to add 
  a temporary
  commit to fix a bug introduced in one of the strncpy/overflow patches 
  that got into
  btrfs-progs. This fix is not part of the btrfs send/receive patchset, 
  but you'll
  probably need it if you want to base on the integration branch. I hope 
  this is not
  required in the future when a new integration branch comes out.
 
  Example usage:
 
  Multiple snapshots at once:
  btrfs send /mnt/snap[123]  snap123.btrfs
 
  a) Do we really want a single token command here, not
  btrfs filesystem send or subvol send?
 In my opinion the single token is easier to type and remember. But if
 enough speaks for normal subcommands this can be changed (but by
 someone else as I'm running out of time).

Since everything else is two commands, yes, I think we need it for
 consistency. (And, since it's a publically-visible interface, for
 acceptance of the patches -- we don't want to be changing the way the
 commands work after the fact).

  b) zfs makes sure stdout is not a tty, to prevent flooding
  your console. This kinda makes sense.
 This makes sense. But again, this has to be done by someone else.

Can you keep a brief list of such cleanups/features and dump it on
 the wiki as a proposed project when your time does run out, please.
 That way the details don't get lost, and they can be found by other
 people and dealt with independently.
 Added a page to the wiki:
 https://btrfs.wiki.kernel.org/index.php/Btrfs_Send/Receive

Hugo.

 --
 === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
   PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
 --- Turning,  pages turning in the widening bath, / The spine ---
 cannot bear the humidity. / Books fall apart; the binding
 cannot hold. / Page 129 is loosed upon the world.
 --
 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
--
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


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-25 Thread Alexander Block
On Wed, Jul 25, 2012 at 7:10 PM, Alex Lyakas
alex.bolshoy.bt...@gmail.com wrote:
 Alexander,
 can you pls let know like a day or two before you run out of time?
 I have compiled a list of questions, but also want to do more testing
 before I publish them all.
My flight goes on 6. August...after that I don't know when I'm back. I
try my best to work on the most important issues until then, but time
is very limited already now due to the preparations I need to take
care of.

 Thanks for your work,
 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


[RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-04 Thread Alexander Block
Hello all,

This is the user space side of btrfs send/receive.

You can apply them manually or use my git repo:

git://github.com/ablock84/btrfs-progs.git (branch send)

The branch is based on Hugo's integration-20120605 branch. I had to add a 
temporary
commit to fix a bug introduced in one of the strncpy/overflow patches that got 
into
btrfs-progs. This fix is not part of the btrfs send/receive patchset, but you'll
probably need it if you want to base on the integration branch. I hope this is 
not
required in the future when a new integration branch comes out.

Example usage:

Multiple snapshots at once:
btrfs send /mnt/snap[123]  snap123.btrfs

Single snapshot with manual parent:
btrfs send -p /mnt/snap3 /mnt/snap4  snap4.btrfs

Receive both streams:
btrfs receive /mnt2  snap123.btrfs
btrfs receive /mnt2  snap4.btrfs

(Please give suggestions for a file extension)

Please read the kernel side email as well, especially the warnings!

Alex.

Alexander Block (6):
  Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h
  Btrfs-progs: update ioctl.h to support clone range ioctl
  Btrfs-progs: print inode transid and dir item data field in
debug-tree
  Btrfs-progs: update btrfs-progs for subvol uuid+times support
  Btrfs-progs: update ioctl.h to support btrfs send ioctl
  Btrfs-progs: add btrfs send/receive commands

 Makefile   |7 +-
 btrfs.c|2 +
 cmds-receive.c |  910 
 cmds-send.c|  677 +
 commands.h |4 +
 ctree.h|   40 ++-
 ioctl.h|   35 ++-
 print-tree.c   |   88 --
 send-stream.c  |  480 ++
 send-stream.h  |   58 
 send-utils.c   |  337 +
 send-utils.h   |   69 +
 send.h |  132 
 13 files changed, 2815 insertions(+), 24 deletions(-)
 create mode 100644 cmds-receive.c
 create mode 100644 cmds-send.c
 create mode 100644 send-stream.c
 create mode 100644 send-stream.h
 create mode 100644 send-utils.c
 create mode 100644 send-utils.h
 create mode 100644 send.h

-- 
1.7.10

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


Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)

2012-07-04 Thread Chris Mason
On Wed, Jul 04, 2012 at 07:39:28AM -0600, Alexander Block wrote:
 Hello all,
 
 This is the user space side of btrfs send/receive.
 
 You can apply them manually or use my git repo:
 
 git://github.com/ablock84/btrfs-progs.git (branch send)
 
 The branch is based on Hugo's integration-20120605 branch. I had to add a 
 temporary
 commit to fix a bug introduced in one of the strncpy/overflow patches that 
 got into
 btrfs-progs. This fix is not part of the btrfs send/receive patchset, but 
 you'll
 probably need it if you want to base on the integration branch. I hope this 
 is not
 required in the future when a new integration branch comes out.

Just awesome.  I'm playing with this now.

Except for the arm patch, I have the integration here in final testing
for 0.20.  This stuff will make 0.21 when it is all done.

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