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