public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: "A. James Lewis" <james@fsck.co.uk>
To: linux-bcache@vger.kernel.org
Subject: Re: layering question.
Date: Thu, 06 Aug 2015 01:54:12 +0100	[thread overview]
Message-ID: <55C2B034.2090404@fsck.co.uk> (raw)
In-Reply-To: <poha9c-rh4.ln1@hurikhan77.spdns.de>

The problem is tho... with a very large backing store, I'm not really 
happy with a single point of failure in the cache... is there another 
way to mirror the cache device?

Does anyone make an M.2 raid controller... being PCIe, I don't know it 
that could even be possible.

James

On 06/08/15 00:10, Kai Krakow wrote:
> Jens-U. Mozdzen <jmozdzen@nde.ag> schrieb:
>
>> Zitat von Kai Krakow <hurikhan77@gmail.com>:
>>> 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 [...]
>> being rather new to bcache, I did only browse the last few months of
>> mailing list history - are you saying that these problems were fixed
>> (or simply vanished) some point after 3.18.8? Because if so, I'd of
>> course try to upgrade our servers to a more recent kernel :)
> Latest posts imply it is still a problem. It fits with earlier reports:
> Caching on native device, backing on md device... Bcache breaks within the
> caching device (although this is not on md). There seem to still be bugs
> with bcache and md to properly interact.
>
> It was suspected that bcache uses a faulty discard implementation. Some
> reports miss details about this setting. However, my setups are working fine
> with discards fully enabled on SSD - but without using MD. And it has been
> robust to accidental or implied reboots since all time I'm using it (even
> with btrfs as the filesystem on bcache).
>
> So I'd probably remove MD from your plans on using bcache.
>
> BTW: My system uses vanilla gentoo kernel, 4.1.4 currently.
>

  reply	other threads:[~2015-08-06  0:54 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
2015-08-05  7:04   ` Jens-U. Mozdzen
2015-08-05 23:10     ` Kai Krakow
2015-08-06  0:54       ` A. James Lewis [this message]
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=55C2B034.2090404@fsck.co.uk \
    --to=james@fsck.co.uk \
    --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