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 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.