Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Roger Binns <rogerb@rogerbinns.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/5] [RFC] RAID-level terminology change
Date: Sat, 09 Mar 2013 21:41:50 -0800	[thread overview]
Message-ID: <khh6er$nmk$1@ger.gmane.org> (raw)
In-Reply-To: <20130310014434.GB30771@carfax.org.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/03/13 17:44, Hugo Mills wrote:
> You've got at least three independent parameters to the system in order
> to make that choice, though, and it's a fairly fuzzy decision problem.
> You've got:
> 
> - Device redundancy - Storage overhead - Performance

Overhead and performance aren't separate goals.  More accurately the goal
is best performance given the devices available and constrained by redundancy.

If I have 1GB of unique data and 10GB of underlying space available then
feel free to make 9 additional copies of each piece of data if that helps
performance.  As I increase the unique data the overhead available will
decrease, but I doubt anyone has a goal of micromanaging overhead usage.
Why can't the filesystem just figure it out and do the best job available
given minimal constraints?

> I definitely want to report the results in nCmSpP form, which tells you
> what it's actually done. The internal implementation, while not 
> expressing the full gamut of possibilities, maps directly from the 
> internal configuration to that form, and so it should at least be an 
> allowable input for configuration (e.g. mkfs.btrfs and the restriper).

Agreed on that for the micromanagers :-)

> If you'd like to suggest a usable set of configuration axes [say, 
> (redundancy, overhead) ], and a set of rules for converting those
> requirements to the internal representation, then there's no reason we
> can't add them as well in a later set of patches.

The only constraints that matter are surviving N device failures, and data
not lost if at least N devices are still present.  Under the hood the best
way of meeting those can be heuristically determined, and I'd expect
things like overhead to dynamically adjust as storage fills up or empties.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlE8HR0ACgkQmOOfHg372QSyngCgpE9PTyBl3MsJ1kCYODtQWno/
85cAn0dcqE8ZWhOpFbZnQISmpe/KYceN
=LTf8
-----END PGP SIGNATURE-----


  reply	other threads:[~2013-03-10  5:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-09 20:31 [PATCH 0/5] [RFC] RAID-level terminology change Hugo Mills
2013-03-09 20:31 ` [PATCH 1/5] Use nCmSpP format for mkfs Hugo Mills
2013-03-09 20:31 ` [PATCH 2/5] Move parse_profile to utils.c Hugo Mills
2013-03-09 20:31 ` [PATCH 3/5] Convert balance filter parser to use common nCmSpP replication-level parser Hugo Mills
2013-03-09 20:31 ` [PATCH 4/5] Change output of btrfs fi df to report new (or old) RAID names Hugo Mills
2013-03-09 20:31 ` [PATCH 5/5] Add man page description for nCmSpP replication levels Hugo Mills
2013-03-10 14:01   ` Goffredo Baroncelli
2013-03-10 17:20     ` Hugo Mills
2013-03-10 17:52       ` Goffredo Baroncelli
2013-03-09 21:38 ` [PATCH 0/5] [RFC] RAID-level terminology change Harald Glatt
     [not found] ` <CAFWF=am4ki529Zez4123gYk3BD+Z9RONRpAK7NZe=skHzcdMiw@mail.gmail.com>
2013-03-09 21:46   ` Hugo Mills
2013-03-09 22:25 ` Roger Binns
2013-03-10  1:44   ` Hugo Mills
2013-03-10  5:41     ` Roger Binns [this message]
2013-03-10  6:29       ` Harald Glatt
2013-03-10  6:37         ` Harald Glatt
2013-03-10 11:31           ` Martin Steigerwald
2013-03-10 11:48           ` Roger Binns
2013-03-10 22:04       ` Hugo Mills
2013-03-11  0:21         ` Roger Binns
2013-03-27  4:27           ` Brendan Hide
2013-03-27  5:24             ` Roger Binns
2013-03-10 11:23 ` Martin Steigerwald
2013-03-10 14:11   ` Goffredo Baroncelli
2013-03-10 21:36   ` Hugo Mills
2013-03-10 21:45     ` Harald Glatt
2013-03-10 22:59       ` Goffredo Baroncelli
2013-03-10 22:06         ` Harald Glatt
2013-03-10 23:06   ` Diego Calleja
2013-03-10 15:43 ` Goffredo Baroncelli
2013-03-10 22:24   ` Hugo Mills
2013-03-10 22:42     ` Harald Glatt
2013-03-10 23:40   ` sam tygier
2013-03-10 23:49     ` Hugo Mills
2013-03-11 14:14       ` David Sterba
2013-03-10 23:55 ` sam tygier
2013-03-11  8:56   ` Hugo Mills

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='khh6er$nmk$1@ger.gmane.org' \
    --to=rogerb@rogerbinns.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