From: Psalle <psalleetsile@gmail.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: SSD caching an existing btrfs raid1
Date: Wed, 20 Sep 2017 17:51:15 +0200 [thread overview]
Message-ID: <36669362-6401-72e3-f963-41de0debd0a4@gmail.com> (raw)
In-Reply-To: <2a208f7c-a140-3ac6-12c6-2e953f3f96ec@gmail.com>
On 19/09/17 17:47, Austin S. Hemmelgarn wrote:
(...)
>
> A better option if you can afford to remove a single device from that
> array temporarily is to use bcache. Bcache has one specific advantage
> in this case, multiple backend devices can share the same cache
> device. This means you don't have to carve out dedicated cache space
> for each disk on the SSD and leave some unused space so that you can
> add new devices if needed. The downside is that you can't convert
> each device in-place, but because you're using BTRFS, you can still
> convert the volume as a whole in-place. The procedure for doing so
> looks like this:
>
> 1. Format the SSD as a bcache cache.
> 2. Use `btrfs device delete` to remove a single hard drive from the
> array.
> 3. Set up the drive you just removed as a bcache backing device bound
> to the cache you created in step 1.
> 4. Add the new bcache device to the array.
> 5. Repeat from step 2 until the whole array is converted.
>
> A similar procedure can actually be used to do almost any underlying
> storage conversion (for example, switching to whole disk encryption,
> or adding LVM underneath BTRFS) provided all your data can fit on one
> less disk than you have.
Thanks Austin, that's just great. For some reason I had discarded bcache
thinking that it would force me to rebuild from scratch, but this kind
of incremental migration is exactly why I hoped was possible. I have
plenty of space to replace the devices one by one.
I will report back my experience in a few days, I hope.
next prev parent reply other threads:[~2017-09-20 15:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 15:30 SSD caching an existing btrfs raid1 Pat Sailor
2017-09-19 15:47 ` Austin S. Hemmelgarn
2017-09-20 1:58 ` Duncan
2017-09-20 15:51 ` Psalle [this message]
2017-09-20 20:45 ` Kai Krakow
2017-09-21 6:23 ` Paul Jones
2017-09-21 16:49 ` Psalle
2017-09-20 1:33 ` Paul Jones
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=36669362-6401-72e3-f963-41de0debd0a4@gmail.com \
--to=psalleetsile@gmail.com \
--cc=ahferroin7@gmail.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;
as well as URLs for NNTP newsgroup(s).