public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: linux-bcache@vger.kernel.org
Subject: Re: bcache and LVM
Date: Mon, 08 Feb 2016 14:02:52 -0800	[thread overview]
Message-ID: <87r3gmrhbn.fsf@thinkpad.rath.org> (raw)
In-Reply-To: 20160208144419.Horde.Ci1_2KcBCEnOa-WxsDN90oU@www3.nde.ag

On Feb 08 2016, "Jens-U. Mozdzen" <jmozdzen@nde.ag> wrote:
> Hi Nikolaus,
>
> Zitat von Nikolaus Rath <Nikolaus@rath.org>:
>> Hello,
>>
>> The internet claims that using bcache with LVM is not a good idea
>> (eg. on https://wiki.archlinux.org/index.php/Bcache )- but I wasn't able
>> to find any substantial information other than this general
>> recommendation.
>
> looking at that article, it only references possibly ill-handled
> "discard" operations, when running bcache on top of LVM.

Well, it says:

| Warning:
| 
|     it is widely recommended to use Bcache underneath any other block
|    layer.


To me this implies that running it on top of another block layer is
dangerous (why warn about it otherwise?). 

> The article itself does positively mention sub-dividing bcache devices
> using LVM.

Yep, but the talk page then says:

| Initially, LVM did not recognize my /dev/bcache0 when I wanted to
| create a physical volume on it. For anyone else who has that issue,
| this may be relevant:
| http://www.redhat.com/archives/linux-lvm/2012-March/msg00005.html.


>> Is this still (or has ever been) correct? If so, what issues can arise?
>> And does this happen only when using bcache on top of an LVM LV, or also
>> when using a bcache device as an LVM PV?
>
> We're running bcache between MD-RAID (RAID6 for the HDD backing store
> and RAID1 for caching SSDs) and LVM2 (using bcache0 as the only PV for
> the volume group) without any noticeable problem, for moderate to
> significant load (SAN/NAS servers with NFS, Samba, and virtual
> machines' storage via SCST/FC and SCST/iSCSI).

Thanks for the datapoint! What kernel version do you use?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

  reply	other threads:[~2016-02-08 22:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-07 17:20 bcache and LVM Nikolaus Rath
2016-02-08 13:44 ` Jens-U. Mozdzen
2016-02-08 22:02   ` Nikolaus Rath [this message]
2016-02-09 10:44     ` Jens-U. Mozdzen
2016-02-09 16:02       ` Nikolaus Rath
2016-02-09 16:35         ` Jens-U. Mozdzen
2016-02-10  4:09 ` Nikolaus Rath
2016-02-24  7:18   ` bcache and LVM --- works great Eric Wheeler

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=87r3gmrhbn.fsf@thinkpad.rath.org \
    --to=nikolaus@rath.org \
    --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