From: Nix <nix@esperi.org.uk>
To: Postgarage Graz IT <it@postgarage.at>
Cc: linux-bcache@vger.kernel.org
Subject: Re: reads no longer cached since kernel 4.19
Date: Mon, 17 Feb 2020 14:31:47 +0000 [thread overview]
Message-ID: <87sgj9thd8.fsf@esperi.org.uk> (raw)
In-Reply-To: <98d03769-c58d-98dc-64aa-7d8fbf39ceea@postgarage.at> (Postgarage Graz's message of "Wed, 12 Feb 2020 07:02:28 +0100")
On 12 Feb 2020, Postgarage Graz stated:
> On 10.02.20 17:10, Ville Aakko wrote:
>> Hi,
>>
>> A fellow user responding here.
>>
>> I've noticed similar behavior and have asked on this same mailing list
>> previously. See:
>> https://www.spinics.net/lists/linux-bcache/msg07859.html
>>
>> Also seems there are other users with this issue on the Arch Forum,
>> where I have also started a discussion:
>> https://bbs.archlinux.org/viewtopic.php?id=250525
>> There is yet to be a single user to reply there (or on this mailing
>> list) claiming they have a working setup (for caching reads).
>>
>> Judging from the Arch Linux thread, I have a hunch there were some
>> changes ~4.18, which broke read caching for many (all?) desktop users
>> (as anything which is flagged as readahed will not be cached, despite
>> setting sequential_cutoff). Also (again from the Arch thread) a
>> planned patch might enable expected read caching: "[PATCH 3/5] bcache:
>> add readahead cache policy options via sysfs interface" / see:
>> https://www.spinics.net/lists/linux-bcache/msg08074.html
>
> Indeed that patch works.
> Now I'm using the 5.6-rc1 kernel and the performance gain is huge.
Note: 4.19 had an *extra* bug as well, which eliminated all metadata
caching on some filesystems (like XFS, but IIRC not ext4). It was fixed
in v5.1 by commit dc7292a5bcb4c878b.
So you had two problems :)
(I've just moved to a readahead-caching kernel, and while I don't see
any performance gain yet, I'm sure it will come once the cache finishes
populating. It's certainly seeing more writes, 20GiB written in only two
days where before it took a month to write that much.)
Note: the readahead fix was well-timed, since it was only in v5.4 that
the Linux NFS client stopped hardwiring a readahead size of 15 times the
optimal read size, i.e., uh, 15MiB with most servers. That really would
have filled the bcache of the NFS server with a lot of junk.)
next prev parent reply other threads:[~2020-02-17 14:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b039d510-9b03-e6a3-499a-1dbe72764cbe@postgarage.at>
2020-02-12 6:02 ` reads no longer cached since kernel 4.19 Postgarage Graz IT
2020-02-12 9:33 ` Matthias Ferdinand
2020-02-12 10:03 ` Postgarage Graz IT
2020-02-12 20:32 ` Ville Aakko
2020-02-13 11:00 ` Matthias Ferdinand
2020-02-17 14:31 ` Nix [this message]
2020-02-09 21:31 Postgarage Graz IT
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=87sgj9thd8.fsf@esperi.org.uk \
--to=nix@esperi.org.uk \
--cc=it@postgarage.at \
--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;
as well as URLs for NNTP newsgroup(s).