public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Anopolsky <erpo41@gmail.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: parity data
Date: Mon, 08 Sep 2008 18:46:46 -0600	[thread overview]
Message-ID: <1220921206.7953.32.camel@telesto> (raw)
In-Reply-To: <1220885271.8537.31.camel@think.oraclecorp.com>

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

On Mon, 2008-09-08 at 10:47 -0400, Chris Mason wrote:
> On Sat, 2008-09-06 at 23:43 -0600, Eric Anopolsky wrote:
> > Hi,
> > 
> > A couple of questions.
> > 
> > 1. Does btrfs currently have anything like raid 5 or 6?
> > 
> 
> Not yet, it might one day.
> 
> > 2. One guy on my LUG's mailing list is really excited about the
> > potential for setting redundancy on a per-file basis.
> > I.e. /home/eric/criticalfile gets mirrored across all of the drives in
> > the filesystem but /home/eric/temporaryfile gets striped. I'm skeptical.
> > Is it a good idea to allow people/programs to do this?
> 
> In general, yes.  Some files or directories are crucial, and some (swap
> for example) don't need to survive a crash.

If a disk dies in a redundant configuration, I'd like to be able to hot
replace the failed disk and keep going without any interruption. So
losing parts of the paging file would be pretty bad in that case.

Isn't a partially failed array (where some files are accessible and
others are not, without any additional filesystem damage) a weird
failure mode? Do people know how to deal with this? Do applications know
how to deal with this?

What kind of file would be important enough to keep around but
unimportant enough that it could be lost at any time while the system is
up without anyone knowing or caring?

> But, I think the flexibility should go a little further.  The goal is to
> be able to define drive groups and tie files or directory trees to the
> drive groups.  That way you can say these files go to the fastest drives
> and these files go to some other drive type, etc etc.

Let's say I have 4 100GB drives (2 fast ones and 2 slow ones). I've
restricted a performance critical directory to the two fastest drives,
currently totaling 100GB of performance critical data. The rest of the
data on the system is striped.

How much free space do I have on the filesystem? 100GB (the amount of
data I can store in the performance critical directory)? 200GB (the
amount of data I can store outside the performance critical directory if
the striping is guaranteed)? 300GB (the amount of data I can store
outside the performance critical directory if the striping is best
effort)?

I'm open to being convinced otherwise, but I think issues like this
would crop up any time the filesystem is artificially prevented from
load balancing the data across the drives.

Cheers,
Eric


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

  reply	other threads:[~2008-09-09  0:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-07  5:43 parity data Eric Anopolsky
2008-09-08 14:47 ` Chris Mason
2008-09-09  0:46   ` Eric Anopolsky [this message]
2008-09-09 10:43     ` Chris Mason
2008-09-09 14:07       ` Paul P Komkoff Jr
2008-09-10  1:32       ` Eric Anopolsky
2008-09-10 12:59         ` 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=1220921206.7953.32.camel@telesto \
    --to=erpo41@gmail.com \
    --cc=chris.mason@oracle.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