All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Alexander Block <ablock84@googlemail.com>
Cc: Arne Jansen <sensille@gmx.net>, linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs)
Date: Wed, 25 Jul 2012 15:00:36 +0100	[thread overview]
Message-ID: <20120725140036.GE30007@carfax.org.uk> (raw)
In-Reply-To: <CAB9VWqAGTOttaz722LnMiufPNUZaLQU7epAdGFejK9gssuHnRg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

On Wed, Jul 25, 2012 at 12:41:56PM +0200, Alexander Block wrote:
> On Mon, Jul 23, 2012 at 2:29 PM, Arne Jansen <sensille@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.            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2012-07-25 14:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04 13:39 [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs) Alexander Block
2012-07-04 13:39 ` [RFC PATCH 1/6] Btrfs-progs: add BTRFS_IOC_SUBVOL_GET/SETFLAGS to ioctl.h Alexander Block
2012-07-04 13:39 ` [RFC PATCH 2/6] Btrfs-progs: update ioctl.h to support clone range ioctl Alexander Block
2012-07-04 13:39 ` [RFC PATCH 3/6] Btrfs-progs: print inode transid and dir item data field in debug-tree Alexander Block
2012-07-04 13:39 ` [RFC PATCH 4/6] Btrfs-progs: update btrfs-progs for subvol uuid+times support Alexander Block
2012-07-04 13:39 ` [RFC PATCH 5/6] Btrfs-progs: update ioctl.h to support btrfs send ioctl Alexander Block
2012-07-04 13:39 ` [RFC PATCH 6/6] Btrfs-progs: add btrfs send/receive commands Alexander Block
2012-07-09 18:59   ` Alex Lyakas
2012-07-19 13:25     ` Alex Lyakas
2012-07-24 20:27       ` Alexander Block
2012-07-25  9:15         ` Alex Lyakas
2012-07-27 14:06   ` Arne Jansen
2012-07-04 14:53 ` [RFC PATCH 0/6] Experimental btrfs send/receive (btrfs-progs) Chris Mason
2012-07-23 12:29 ` Arne Jansen
2012-07-25 10:41   ` Alexander Block
2012-07-25 14:00     ` Hugo Mills [this message]
2012-07-25 15:17       ` Chris Mason
2012-07-25 16:56       ` Alexander Block
2012-07-25 17:10         ` Alex Lyakas
2012-07-25 17:14           ` Alexander Block

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=20120725140036.GE30007@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=ablock84@googlemail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sensille@gmx.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.