public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: layering question.
Date: Wed, 05 Aug 2015 08:28:04 +0200	[thread overview]
Message-ID: <k0n89c-dgn.ln1@hurikhan77.spdns.de> (raw)
In-Reply-To: 55C0E63F.2030007@fsck.co.uk

A. James Lewis <james@fsck.co.uk> schrieb:

> I've heard rumours that layering bcache with other block device drivers
> might not be recommended... I wonder what the truth really is... perhaps
> someone can advise.

I think this is not just rumours. Multiple people reported problems when 
layering caching or backing devices on top of MD devices. This may be an 
implementation problem in MD which is gone in later kernel versions and had 
to do with correctly passing discards through the layers. If you want to use 
that, I'd at least recommend to disable discards, and to disable write-back 
caching (just use write-through or write-around which is obviously slower 
but might fit you workload).

> I was planning to use 2 SSD's... combined with 4 large spinning drives
> to create a large filesystem with BTRFS...  my questions are as follows.

Using one SSD with 3 spinning drives here.

> 1. Is there a way to use 2 SSD's directly, or would it be OK to use MD
> to stripe them?... then used the MD array as the cache device?

I think currently you can only add on caching device to a cache set. I think 
it is planned to allow that in a later development stage but currently your 
only way to go would be a MD array if you want to use MD. I'd better suggest 
to use hardware RAID for that.

> 2. I would be using BTRFS, so would it be better to create 4 separate
> bcache devices each attached to the single cache device, and then use
> BTRFS to raid 4 bcache devices... obviously this would be more flexible,
> or would I need to make an MD raid of the 4 devices, and then use that
> to create a single bcache device and build a BTRFS filesystem on top of
> that.

You can just attach multiple backing devices (each sub device of your btrfs 
pool) to the same cache set - so you caching device would cache all backing 
devices.

> Hope that's clear, any clarification would be appreciated...

I'd go with the following setup:

I'm not sure which btrfs RAID level you are going to use. Maybe RAID 10, 
probably RAID 0. This means, btrfs tries to evenly spread writes and reads 
across all devices.

I suggest using 2 cache sets. One bcache for btrfs pool member 1 and 2, one 
bcache or btrfs pool member 3 and 4. If you add more members to the pool 
later, just attach them in alternating order to the first or second cache 
set.

This should give you most value out of your current setup.

If you plan to use 2 SSDs for improved reboustness (combined into RAID 1), 
you obviously don't have this option. You could try with MDRAID tho I 
wouldn't recommend this without doing your tests and backups. Better use 
hardware RAID then, tho most controllers will disable the ability to use 
discard then so you probably want to leave some spare space unused on your 
SSDs for improved life time and long-term performance.

> Also, there's talk about a pending on-disk cache format change some time
> around 3.19, but no details... is this over with, or still pending?

No idea, I'm on 4.1 now and used bcache since 3.18 or 3.19 - not sure. It 
worked well.

PS: Disable "autodefrag" if you use btrfs+bcache... ;-) It helps performance 
a bit but it eats SSD lifetime (used 20% of my proposed SSD lifetime in only 
2 months - according to smartctl). Better just defragment meta data from 
time to time (read: use btrfs defrag on directories only) if you want to 
defrag.

-- 
Replies to list only preferred.

  parent reply	other threads:[~2015-08-05  6:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04 16:20 layering question A. James Lewis
2015-08-04 17:01 ` Jens-U. Mozdzen
2015-08-04 17:16   ` A. James Lewis
2015-08-05  6:56     ` Jens-U. Mozdzen
2015-08-05  6:28 ` Kai Krakow [this message]
2015-08-05  7:04   ` Jens-U. Mozdzen
2015-08-05 23:10     ` Kai Krakow
2015-08-06  0:54       ` A. James Lewis
2015-08-06 23:12         ` Kai Krakow
2015-08-07 12:43           ` Jens-U. Mozdzen
2015-08-07 14:38             ` A. James Lewis
2015-08-07 15:36               ` Jens-U. Mozdzen
2015-08-07 16:16                 ` A. James Lewis
  -- strict thread matches above, loose matches on Subject: below --
2015-08-07 16:24 Jens-U. Mozdzen

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=k0n89c-dgn.ln1@hurikhan77.spdns.de \
    --to=hurikhan77@gmail.com \
    --cc=linux-bcache@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