All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Fasheh <mfasheh@suse.de>
To: Arne Jansen <lists@die-jansens.de>
Cc: chris.mason@fusionio.com, linux-btrfs@vger.kernel.org,
	ablock84@googlemail.com, aschnell@suse.de, Anand.Jain@oracle.com
Subject: Re: [PATCH 0/4] btrfs-progs: better support for external users of send, V2
Date: Fri, 18 Jan 2013 13:44:53 -0800	[thread overview]
Message-ID: <20130118214453.GW12558@wotan.suse.de> (raw)
In-Reply-To: <50F79C81.4050100@die-jansens.de>

On Thu, Jan 17, 2013 at 07:38:57AM +0100, Arne Jansen wrote:
> Splitting out the send/receive-specific parts into a lib is a great idea.
> The original motivation behind our send stream format was to make it readily
> receivable on different filesystems.

Oh ok cool. I didn't actually know that it was meant to be used across
multiple file systems. Seems like a pretty neat feature to me :)


> For this we need a generic receiver which could be based on the lib. But to
> make this possible, all btrfs-specific parts need to be kept out of it, so
> it can readily compile on BSD for example.
> So it might make sense to split out 2 parts, one for the pure receive
> functionality and one with the btrfs-specific parts.
> The former lib could be named libfar, as this is the name we want to give
> the stream format to make it independent from btrfs. FAR stands for
> Filesystem Agnostic Replication. There are senders for other systems (especially
> zfs) in preparation.
> I don't know if this affects your efforts in any way, but it might be easiest
> to do the split right away while you're at it :)

Hmm, splitting into two libs isn't really that hard or anything but the real
work (as you note) would be in making it compile in other places. Honestly,
I think that could be built right on top of these patches but I don't feel
that it's within the scope of my current series.
	--Mark

--
Mark Fasheh

      reply	other threads:[~2013-01-18 21:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 22:30 [PATCH 0/4] btrfs-progs: better support for external users of send, V2 Mark Fasheh
2013-01-16 22:30 ` [PATCH 1/4] btrfs-progs: Add support for BTRFS_SEND_FLAG_NO_FILE_DATA Mark Fasheh
2013-01-16 22:30 ` [PATCH 2/4] btrfs-progs: libify some parts of btrfs-progs Mark Fasheh
2013-01-16 22:30 ` [PATCH 3/4] btrfs-progs: add send-test Mark Fasheh
2013-01-16 22:30 ` [PATCH 4/4] btrfs-progs: make libbtrfs usable from C++ Mark Fasheh
2013-01-17  6:38 ` [PATCH 0/4] btrfs-progs: better support for external users of send, V2 Arne Jansen
2013-01-18 21:44   ` Mark Fasheh [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=20130118214453.GW12558@wotan.suse.de \
    --to=mfasheh@suse.de \
    --cc=Anand.Jain@oracle.com \
    --cc=ablock84@googlemail.com \
    --cc=aschnell@suse.de \
    --cc=chris.mason@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@die-jansens.de \
    /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.