On 2016-05-17 02:27, Ferry Toth wrote:
Op Mon, 16 May 2016 01:05:24 +0200, schreef Kai Krakow:

Am Sun, 15 May 2016 21:11:11 +0000 (UTC)
schrieb Duncan <[email protected]>:

Ferry Toth posted on Sun, 15 May 2016 12:12:09 +0000 as excerpted:

<snip>

You can go there with only one additional HDD as temporary storage. Just
connect it, format as bcache, then do a "btrfs dev replace". Now wipe
that "free" HDD (use wipefs), format as bcache, then... well, you get
the point. At the last step, remove the remaining HDD. Now add your
SSDs, format as caching device, and attach each individual HDD backing
bcache to each SSD caching bcache.

Devices don't need to be formatted and created at the same time. I'd
also recommend to add all SSDs only in the last step to not wear them
early with writes during device replacement.

If you want, you can add one additional step to get the temporary hard
disk back. But why not simply replace the oldest hard disk with the
newest. Take a look at smartctl to see which is the best candidate.

I went a similar route but without one extra HDD. I had three HDDs in
mraid1/draid0 and enough spare space. I just removed one HDD, prepared
it for bcache, then added it back and removed the next.

That's what I mean, a lot of work. And it's still a cache, with
unnecessary copying from the ssd to the hdd.
On the other hand, it's actually possible to do this all online with BTRFS because of the reshaping and device replacement tools.

In fact, I've done even more complex reprovisioning online before (for example, my home server system has 2 SSD's and 4 HDD's, running BTRFS on top of LVM, I've at least twice completely recreated the LVM layer online without any data loss and minimal performance degradation).

And what happens when either a hdd or ssd starts failing?
I have absolutely no idea how bcache handles this, but I doubt it's any better than BTRFS.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to