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: Tue, 09 Sep 2008 19:32:06 -0600 [thread overview]
Message-ID: <1221010326.14596.9.camel@telesto> (raw)
In-Reply-To: <1220957012.29741.38.camel@think.oraclecorp.com>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
> > 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)?
> >
>
> People already create these configurations, they just do it with
> multiple filesystems. And, when they want to resize the performance
> critical section, it is a difficult (and often slow) operation.
I think I'm starting to get it. btrfs would have drive groups, and no
file would have data on more than one drive group at once. That would
make it possible to make meaningful statements about how much free disk
space there is (per drive group). This is almost the same as having
multiple filesystems, except files cannot be assigned to filesystems on
an individual basis. So in a way, btrfs would be replacing some
functionality of the VFS (mapping files to filesystems).
Is that right?
Cheers,
Eric
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-09-10 1:32 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
2008-09-09 10:43 ` Chris Mason
2008-09-09 14:07 ` Paul P Komkoff Jr
2008-09-10 1:32 ` Eric Anopolsky [this message]
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=1221010326.14596.9.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