linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: deadhorseconsulting <deadhorseconsulting@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Actual effect of mkfs.btrfs -m raid10 </dev/sdX> ... -d raid10 </dev/sdX> ...
Date: Thu, 21 Nov 2013 12:14:13 -0500	[thread overview]
Message-ID: <528E3F65.4020806@suse.com> (raw)
In-Reply-To: <CAEWPe=pwpxdYUDk7BzfjR8h-Jq9wtQE+gxxQChjOZzsXJO4vHQ@mail.gmail.com>

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

On 11/19/13, 12:12 AM, deadhorseconsulting wrote:
> In theory (going by the man page and available documentation, not 100%
> clear) does the following command indeed actually work as advertised
> and specify how metadata should be placed and kept only on the
> "devices" specified after the "-m" flag?
> 
> Thus given the following example:
> mkfs.btrfs -L foo -m raid10 <ssd> <ssd> <ssd> <ssd> -d raid10 <rust>
> <rust> <rust> <rust>
> 
> Would btrfs stripe/mirror and only keep metadata on the 4 specified SSD devices?
> Likewise then stripe/mirror and only keep data on the specified 4 spinning rust?
> 
> In trying and creating this type of setup it appears that data is also
> being stored on the devices specified as "metadata devices". This is
> observed through via a "btrfs filesystem show". after committing a
> large amount of data to the filesystem The data devices have balanced
> data as expected with plenty of free space but the SSD device are
> reported as either nearly used or completely used.

Others have noted that's not how it works, but I wanted to add a comment.

I had a feature request from a customer recently that was pretty much
exactly this. I think it'd be pretty easy to implement by allocating all
(except for overhead) of the devices to chunks immediately at mkfs time,
bypassing the kernel's dynamic chunk allocation. Since you don't *want*
to mix allocation profiles, the usual reason for doing it dynamically
doesn't apply. Extending an existing file system created in a such a
manner so that the added devices are set up with the right kinds of
chunks would require other extensions, though.

I have a few things on my plate right now, but I'll probably dig into
this in the next month or so.

-Jeff

-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

      parent reply	other threads:[~2013-11-21 17:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19  5:12 Actual effect of mkfs.btrfs -m raid10 </dev/sdX> ... -d raid10 </dev/sdX> deadhorseconsulting
2013-11-19  9:06 ` Hugo Mills
2013-11-19 19:24   ` deadhorseconsulting
2013-11-19 21:04     ` Duncan
2013-11-20  6:41     ` Martin
2013-11-19 23:16   ` Duncan
2013-11-20  6:35     ` Martin
2013-11-20 10:16       ` Chris Murphy
2013-11-20 10:22         ` Russell Coker
2013-11-20  8:09     ` Hugo Mills
2013-11-20 16:43       ` Duncan
2013-11-20 16:52         ` Hugo Mills
2013-11-20 21:13           ` Duncan
2013-11-21 17:14 ` Jeff Mahoney [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=528E3F65.4020806@suse.com \
    --to=jeffm@suse.com \
    --cc=deadhorseconsulting@gmail.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).