Re: [PATCH] xfs: add per-mount read/write I/O completion counters

[Carlos Maiolino]

On Sun, Aug 30, 2026 at 06:47:00PM -0600, Eric Peterson wrote:
> On Mon, Aug 31, 2026 at 07:26:52AM +1000, Dave Chinner wrote:
> > Hence this really doesn't seem like something we should be trying to
> > infer from indirect filesystem stats. Why can't you use the bdev
> > stats to get the actual filesystem wide queue depth information?
> 
> The block device measures the device queue, which is a different
> quantity than filesystem outstanding I/O - not just a lower-layer view
> of the same thing.
> 
> Below are three cases where filesystem queue depth is not what the block
> layer sees:
> 
> 1. Cache hits never reach the block layer. Under a heavy read workload
>    with a warm cache, a large share of ops are serviced from the page
>    cache and are never seen at the block level. Device queue depth can
>    sit near zero while the filesystem is servicing a very high op rate.
> 
> 2. Filesystem ops don't map 1:1 to block I/O. A single read or write can
>    produce one block I/O, several (metadata, readahead, writeback
>    coalescing), or none at all. So device queue depth isn't the
>    filesystem's outstanding-operation count.
> 
> 3. Work can be outstanding inside the filesystem before any block I/O is
>    issued - waiting on locks, log space/reservation, delalloc, etc.
>    Such I/O has entered the filesystem but is invisible at the bdev.

Could you please put those in the commit description? For historic
purposes would be good to keep track why this has been added (or not).


> 
> The block-device queue depth answers "how deep is the device queue,"
> which is not the same as "how much work is outstanding in the
> filesystem." When the filesystem is just one layer an I/O passes
> through, the block stats fold the layers together and structurally
> cannot isolate the filesystem's own contribution.
> 
> To be clear about scope: I'm not proposing a queue-depth feature in
> the kernel. The change just adds read/write completion counters to pair
> with the existing call (submission) counters, so userspace can compute
> outstanding I/O and derive a response-time estimate itself. The kernel
> side is only exposing the complementary raw signal that's currently
> missing - calls are counted, completions are not.
> 
> Being upfront: what userspace derives from this is an instantaneous
> approximation, not a precise time-weighted queue length. It's meant as
> a cheap, always-on aggregate, not a replacement for accurate per-op
> tooling.
> 
> Does exposing the completion side of the existing call counters seem
> reasonable on that basis?
> 

Particularly I liked the idea and the justification seems fair although
I'd want to see the justification for the counter in the patch
description.

Carlos

> -Eric
>