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:42:29 +0500 [thread overview]
Message-ID: <20200331224229.1c216ab2@natsu> (raw)
In-Reply-To: <CAJtFHUQbcVSQw1tQzCKEtHegJT81QzTu9OkCo2bonVpMyryRyQ@mail.gmail.com>
On Tue, 31 Mar 2020 13:31:19 -0400
Eli V <eliventer@gmail.com> wrote:
> Yes using lvm cache is an option, and will give you actual caching of
> the data files as well. However, in my experience it doesn't do much
> caching of metadata so using it on large filesystems doesn't seem to
> improve interactive usage much at all, i.e. ls -l, or btrfs filesystem
> usage etc.
Forgot to mention that in my case (on a large media server) I had great
results with the described setup, especially noticeable in the mount time.
Walking large directories in a GUI file manager was more responsive too. Not
to mention mass deletion of snapshots. LVM cache seemed to know well to avoid
polluting itself with infrequently accessed sequential-pattern bulk operations
(i.e. copying or reading back the actual file data) and appeared to cache
mostly the metadata as it should. For anyone considering this, give it a try,
and give it at least a few days of normal usage to properly warm up.
--
With respect,
Roman
next prev parent reply other threads:[~2020-03-31 17:42 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
2020-03-31 17:31 ` Eli V
2020-03-31 17:42 ` Roman Mamedov [this message]
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=20200331224229.1c216ab2@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.