All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Eli V <eliventer@gmail.com>
Cc: Paul Jones <paul@pauljones.id.au>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	Victor Hooi <victorhooi@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Using Intel Optane to accelerate a BTRFS array? (equivalent of ZLOG/SIL for ZFS?)
Date: Tue, 31 Mar 2020 22:17:49 +0500	[thread overview]
Message-ID: <20200331221749.52b10248@natsu> (raw)
In-Reply-To: <CAJtFHUSjwBKGyjSQfB-aZwsvV=4AcnG+-h5uF_4zmBOESxd=hA@mail.gmail.com>

On Tue, 31 Mar 2020 13:01:09 -0400
Eli V <eliventer@gmail.com> wrote:

> Another option is to put the 12TB drives in an mdadm RAID, and then
> use the mdadm raid & the ssd for btrfs RAID1 metadata, with SINGLE
> data on the the array. Currently, this will make roughly half of the
> meta data lookups run at SSD speed, but there is a pending patch to
> allow all the metadata reads to go to the SSD. This option is, of
> course, only useful for speeding up metadata operations. It can make
> large btrfs filesystems feel much more responsive in interactive use
> however.

If you're not taking advantage of Btrfs-side features for RAID, then might as
well run LVM Cache on top of mdadm, and then Btrfs on top of the
cached LV.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation
https://lukas.zapletalovi.com/2019/05/lvm-cache-in-six-easy-steps.html

Or Bcache, which is the same concept, but I do not suggest it over LVM cache
due to perceived lower code quality, i.e. many data loss bugs, at least in the
past. And as the 2nd article mentions, you can't un-bcache a block device,
even if the cache device is disabled, the metadata cannot be removed. Unlike
LVM where it is easy to switch back an LV to a plain uncached one.

-- 
With respect,
Roman

  parent reply	other threads:[~2020-03-31 17:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29 22:30 Using Intel Optane to accelerate a BTRFS array? (equivalent of ZLOG/SIL for ZFS?) Victor Hooi
2020-03-30  5:46 ` Andrei Borzenkov
2020-03-30  6:00   ` Paul Jones
2020-03-31 17:01     ` Eli V
2020-03-31 17:09       ` Andrei Borzenkov
2020-03-31 20:08         ` Goffredo Baroncelli
2020-03-31 21:44           ` Goffredo Baroncelli
2020-03-31 17:17       ` Roman Mamedov [this message]
2020-03-31 17:31         ` Eli V
2020-03-31 17:42           ` Roman Mamedov
2020-03-31 19:46             ` Eli V

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=20200331221749.52b10248@natsu \
    --to=rm@romanrm.net \
    --cc=arvidjaar@gmail.com \
    --cc=eliventer@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=paul@pauljones.id.au \
    --cc=victorhooi@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.