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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox