From: Christophe Varoqui <christophe.varoqui@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: [ANNOUNCE] opensvc btrfs send/receive driver
Date: Tue, 04 Sep 2012 16:23:20 +0200 [thread overview]
Message-ID: <1346768600.27224.29.camel@lapoo.opensvc.com> (raw)
Hi list,
OpenSVC >= 120904.1516 now contains a replication driver for the btrfs
send/receive mecanism. This new driver adds up to the zfs, rsync, dds,
netapp, datacore and drbd existing drivers.
It is no more mature than btrfs send/receive itself, so don't use in
production clusters for now.
--- background ---
OpenSVC is a GPLv2 cluster resource manager which handles replication to
peer nodes and disaster recovery nodes. More information about it at
http://www.opensvc.com and http://docs.opensvc.com (and specifically
about btrfs here : http://docs.opensvc.com/storage.btrfs.html)
--- background ---
Concerning this btrfs driver, the logic implemented is :
- create @tosent readonly snapshots on sender
- for each subvol-remote pair:
* send/receive the @tosent snap
* rotate @tosent to @sent on remote
* recursive clean-up of the destination final location on remote
* install the @sent subvol as rw snapshots on remotes
- rotate @tosent to @sent on sender
I'm interested on your opinion on the sanity of this logic.
Meanwhile, here are the caveats I encountered while developping this
driver :
- no recursive snapshot/delete/send : for now you have to declare one
sync resource per subvol, even if they are organised as a tree. Not a
big deal, but would make the life of users easier and would solve the
multi-snapshot atomocity issue.
- btrfs receive is easily confused when looking for a subvol parent id :
for now opensvc has to mount the ID5 root vol
on /opt/opensvc/var/btrfs/<label> and uses a flat/root-level snapshot
hosting. If the btrfs feature matures we want to move to a .osvcsnap/
dedicated subvol mounted in /opt/opensvc/var/btrfs/<label>.osvcnap/
instead to not expose the whole btrfs structure. Some failure scenarios
I tested included "receive in a subvol" and "receive in a subdir"
- some kernel stacks and hangs when off-roading (trying to delete a
parent subvol for example) ... most on btrfs_get_token_64+0x90/0xca .
Let me know if you are interested in the details.
Anyway, thank you for this much needed feature. This is great work.
Best regards,
Christophe Varoqui
OpenSVC
next reply other threads:[~2012-09-04 14:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 14:23 Christophe Varoqui [this message]
2012-09-04 15:12 ` [ANNOUNCE] opensvc btrfs send/receive driver Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2012-09-04 17:26 Christophe Varoqui
2012-09-04 21:57 ` Chris Mason
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=1346768600.27224.29.camel@lapoo.opensvc.com \
--to=christophe.varoqui@gmail.com \
--cc=christophe.varoqui@opensvc.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).