linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: sri <toyours_sridhar@yahoo.co.in>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs-image and btrfs send related queries
Date: Fri, 15 Apr 2016 12:49:10 +0000	[thread overview]
Message-ID: <20160415124910.GD30971@carfax.org.uk> (raw)
In-Reply-To: <loom.20160415T142724-462@post.gmane.org>

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

On Fri, Apr 15, 2016 at 12:41:36PM +0000, sri wrote:
> Hi,
> 
> I have couple of queries related to btrfs-image, btrfs send and with 
> combination of two.
> 1)
> I would like to know if a btrfs source file system is spread across more 
> than 1 disks, does btrfs-image require same number of disks to create 
> empty file system without files content??

   I don't _think_ you need as many devices as there were originally.

> 2) would btrfs-image can be modified to keep only given subvolume foot 
> print and related meta data to bring back file system live on destination 
> disk?
> 
>    To elaborate more on this, Lets say I have 5 subvolumes on source btrfs 
> and i run btrfs-image written to destination disk say /dev/sdd. In this 
> process, can btrfs-image modified to just have only 1 subvolume and skipp 
> other 4 subvolumes and write to destination i.. /dev/sdd so that when I 
> mount /dev/sdd , I will have btrfs with only 1 subvolume with no data.

   For a first approximation, you could just drop any FS tree from the
image which wasn't the target one. After that, it turns into a
complicated accounting exercise to drop all of the back-refs to the
missing FS trees, and to drop all the extent records for the
non-shared data and the metadata for the missing FS trees.

   It's probably going to be complicated, and will basically involve
rewriting most of the image to avoid the metadata you didn't want.

> 3) If 3 can successful, can btrfs-image further changed to include data of 
> selected subvolume which gives files data also written to /dev/sdd which 
> would be kind of a backup of a subvolume taken out of a btrfs file system 
> which is having more than 1 subvolumes.

   If you're going to do all the hard work of (2), then (3) is a
reasonable logical(?) extension.

   On the other hand, what's wrong with simply using send/receive? It
gives you a data structure (a FAR-format send stream) which contains
everything you need to reconstruct a subvolume on a btrfs different
to the original.

   Hugo.

-- 
Hugo Mills             | Mary had a little lamb
hugo@... carfax.org.uk | You've heard this tale before
http://carfax.org.uk/  | But did you know she passed her plate
PGP: E2AB1DE4          | And had a little more?

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

  reply	other threads:[~2016-04-15 12:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 12:41 btrfs-image and btrfs send related queries sri
2016-04-15 12:49 ` Hugo Mills [this message]
2016-04-15 16:21   ` Henk Slager
2016-04-18  7:24     ` sri
2016-04-18 14:13       ` Henk Slager
2016-04-18 14:26         ` Roman Mamedov
2016-04-18 19:48           ` Henk Slager
2016-04-19  9:39             ` sri
     [not found]             ` <526644665.2251591.1461058513616.JavaMail.yahoo@mail.yahoo.com>
2016-04-19 11:30               ` Henk Slager
2016-04-20 11:50                 ` sri

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=20160415124910.GD30971@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=toyours_sridhar@yahoo.co.in \
    /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).