linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).