From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Krakow Subject: Re: layering question. Date: Fri, 07 Aug 2015 01:12:29 +0200 Message-ID: References: <55C0E63F.2030007@fsck.co.uk> <20150805090446.Horde.VMReCuJzW3PwyI8Gh_BZ_yJ@www3.nde.ag> <55C2B034.2090404@fsck.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Return-path: Received: from plane.gmane.org ([80.91.229.3]:59810 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbbHFXWL (ORCPT ); Thu, 6 Aug 2015 19:22:11 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZNUUA-0006XI-2V for linux-bcache@vger.kernel.org; Fri, 07 Aug 2015 01:22:06 +0200 Received: from ip18864262.dynamic.kabel-deutschland.de ([24.134.66.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Aug 2015 01:22:06 +0200 Received: from hurikhan77 by ip18864262.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Aug 2015 01:22:06 +0200 Sender: linux-bcache-owner@vger.kernel.org List-Id: linux-bcache@vger.kernel.org To: linux-bcache@vger.kernel.org Hi! A. James Lewis schrieb: > 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? Well, AFAIR there are plans to add such capabilities into bcache itself - read: make it possible to add more than one caching device to a cache set. It will use some sort of hybrid mirror / striping to get the best combination of speed and safety - at least that's what the idea is about. I just don't remember where I've read about it, neither do I know the status of it. If you want to eliminate the single point of failure, you may want to try mdadm with its write-mostly option instead of using bcache. It's slower for writes obviously but gracefully falls back if the SSD fails. Obviously, you can also not benefit from having a huge storage because it's classic RAID-1 and thus the smallest member will limit your storage size. Bcache also has countermeasures for a failing caching device but I didn't really look into that yet. You should read the documentation about it in Documentation/bcache.txt (Error Handling). The safest mode to use here is writethrough. > On 06/08/15 00:10, Kai Krakow wrote: >> Jens-U. Mozdzen schrieb: >> >>> Zitat von Kai Krakow : >>>> A. James Lewis 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. >> -- Replies to list only preferred.