From: Roger Binns <rogerb@rogerbinns.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: RAID 0 across SSD and HDD
Date: Wed, 30 Jan 2013 02:49:09 -0800 [thread overview]
Message-ID: <keatr3$65q$1@ger.gmane.org> (raw)
In-Reply-To: <20130130100201.GN16285@carfax.org.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 30/01/13 02:02, Hugo Mills wrote:
> On Wed, Jan 30, 2013 at 01:27:37AM -0800, Roger Binns wrote:
>> In my specific case I have a 250GB SSD and a 500GB HDD, and about
>> 250GB of files (constantly growing). One message I saw said that new
>> blocks are allocated on the device with the most free space which
>> implies the SSD would be virtually unused in my case, except for
>> metadata which would only be used half the time.
>
> That would be the case with "single" mode, not with RAID-0.
Ah, I hadn't realised there was a major difference.
> With RAID-0, you'd get data striped equally across all (in this case,
> both) the devices, up to the size of the second-largest one, at which
> point it'll stop allocating space.
By "stop allocating space" I assume you mean it will return out of space
errors, even though there is technically 250GB of unused space. I presume
there is no way to say that RAID-0 should be used where possible and then
fallback to "single" for the remaining space.
It looks like my choices are:
* RAID 0 and getting 500GB of usable space, with performance 50% of the
accesses at HDD levels and 50% at SSD levels
* Single and getting 750GB of usable space with performance and usage
mostly on the HDD
> We don't have any kind of hot-data management yet, but it's on the list
> of things we'd like to have at some point.
I'm happy to wait till it is available. btrfs has been beneficial to me
in so many other respects (eg checksums, compression, online everything,
not having to deal with LVM and friends). I was just hoping that joining
an SSD and HDD would be somewhat worthwhile now even if it isn't close to
what hot data will deliver in the future.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlEI+qUACgkQmOOfHg372QT/pwCfd0UiGGlQpIjCBtCpysPZtGEs
wEQAoNVIzFIkPp/EzHTDDaD9RD178dkB
=VUqP
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-01-30 10:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 9:27 RAID 0 across SSD and HDD Roger Binns
2013-01-30 10:02 ` Hugo Mills
2013-01-30 10:49 ` Roger Binns [this message]
2013-01-30 12:01 ` Sander
2013-01-30 20:06 ` Roger Binns
2013-01-30 19:10 ` Filipe Brandenburger
2013-01-30 20:18 ` Roger Binns
2013-01-31 12:39 ` Piotr Pawłow
2013-01-30 18:51 ` Chris Murphy
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='keatr3$65q$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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.