Hi, On 11/17/25 17:20, Domhnall McGuigan wrote:
Hi all, I've been investigating a problem with tests of our database processing jobs running on cephfs apparently reading several times more data than actually exists in the working set. I haven't had much luck diagnosing the cause so far, but one possibility I'd at least like to rule out is that the kernel cephfs client is discarding pages with cached reads too aggressively and so we're redundantly reading small chunks of data over and over again. Our access patterns are quite unusual -- we read small chunks (perhaps a few hundred kilobytes) from files, then close the file handles before reopening and doing more reads. I found a 10 year old thread indicating that cephfs would outright clear page caches for files in situations like this: https://ceph-users.ceph.narkive.com/o2vJ4rWf/cephfs-and-page-cache That behaviour was patched out long ago, but I'd like to know whether aggressive page cache eviction like this is still known to be an issue with certain access patterns, even if just to eliminate it as a possibility. We're hosting ceph on the same machines as our database which further makes me wonder if some kind of cache pressure could be involved.
Not a direct answer, but you can use tools like "fincore" from the linux-ftools package to check whether a file is currently cached and also how much of the file is cached. I've used this in the past in a similar case. Some of the flags in the application's open() call triggered a cache flush, but I do not remember the exact circumstances. Best regards, Burkhard