public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Samuel <chris@csamuel.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: multiple device usage
Date: Thu, 1 Jan 2009 12:02:17 +1100	[thread overview]
Message-ID: <200901011202.18060.chris@csamuel.org> (raw)
In-Reply-To: <1230672308.4229.6.camel@think.oraclecorp.com>

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

On Wed, 31 Dec 2008 8:25:08 am Chris Mason wrote:

> This gets confusing in a hurry, but the idea is to duplicate metadata by
> default.  So, if you're using the default mount options on a single
> drive and add a second drive, it should switch metadata to raid1.

Yup, that's what I inferred from your earlier posts and the code. :-)

> I've always planned on adding an option to btrfs-vol -b to have it
> change the data or metadata allocation policies (raidX to raidY,
> restripe etc).  The kernel side code is all there, we just need
> something to wire it up to userland.

Understood.  If I get some Copious Spare Time (tm) I might take a look at that 
(though don't let that stop anyone else trying first!).

> data duplication on a single spindle could work, I just haven't hooked
> it up because I couldn't think of a really strong reason to do it ;)

I think for SSD's it could be really handy, especially for people who have a 
standard distro install and decide they want to convert their ext3 partition 
to btrfs using the tools.   It's just a bit easier than getting them to 
backup, repartition, make the filesystem and restore.

Downside of course is that those original blocks never get mirrored (unless 
something like btrfsck was extended to fix those things up).

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

      reply	other threads:[~2009-01-01  1:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-26 23:15 multiple device usage devzero
2008-12-27  2:44 ` Yan Zheng
2008-12-27 14:12   ` Roland
2008-12-28 13:26     ` yanhai zhu
2008-12-29 10:49       ` Stephan von Krawczynski
2008-12-29 12:31       ` Roland
2008-12-29 12:35         ` Yan Zheng
2008-12-30 21:43           ` Chris Mason
2008-12-27  6:45 ` Chris Samuel
2008-12-29 11:32   ` Chris Samuel
2008-12-29 12:33     ` Yan Zheng
2008-12-29 12:52       ` Chris Samuel
2008-12-29 15:16         ` Yan Zheng
2008-12-30 21:25           ` Chris Mason
2009-01-01  1:02             ` Chris Samuel [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=200901011202.18060.chris@csamuel.org \
    --to=chris@csamuel.org \
    --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