Re: [PATCH v2 5/5] xfs: introduce software write streams

[Dave Chinner <dgc@kernel.org>]

On Mon, Mar 09, 2026 at 10:59:44AM +0530, Kanchan Joshi wrote:
> Even when the underlying block device does not advertise write streams,
> XFS can choose do so as write-stream based AG allocation can improve the
> concurrency and reduce interleaving of concurrent block allocation as well
> as logical fragmentation.

XFS's default allocation policy already does this "stream
separation" implicitly on a per-directory basis. So you're going to
need to be more specific about the workload that can benefit from
software write streams being assigned to specific AGs...

> Use a simple 3-tier (low/medium/high) AG count based heuristic to
> publish streams. This enables logical spatial isolation for standard
> storage, execluding rotational media and rtvolume.

This is completely unnecessary if you use the filestreams allocator
for write streams to do workload separation. There is no special
hardware mapping of streams that we can use, so just an AG per
stream will get you exactly the same stream separation behaviour.

And, FWIW, filestreams works just fine on rotational devices. In
fact, that is what filestreams was designed for: optimising IO
to/from massive isochronous RAID arrays full of spinning disks that
stored uncompressed high definition video streams in file-per-frame
format. Keeping each video stream in a separate AG meant each frame
of a video was placed on sequential RAID stripes and each video
stream hit different disks in the RAID arrays. This mean video
stream reads and writes always did full stripe IO and the IO from
the different streams never interfered with each other.

So, yeah, get rid of the arbitrary "can't use software mappings on
rotational devices" because we know from experience that it is just
not true...

-Dave.
-- 
Dave Chinner
dgc@kernel.org