Re: [PATCH 00/13] Parallelizing filesystem writeback

[Jan Kara <jack@suse.cz>]

On Thu 03-07-25 15:05:00, Christoph Hellwig wrote:
> On Wed, Jul 02, 2025 at 11:43:12AM -0700, Darrick J. Wong wrote:
> > > On a spinning disk, random IO bandwidth remains unchanged, while sequential
> > > IO performance declines. However, setting nr_wb_ctx = 1 via configurable
> > > writeback(planned in next version) eliminates the decline.
> > > 
> > > echo 1 > /sys/class/bdi/8:16/nwritebacks
> > > 
> > > We can fetch the device queue's rotational property and allocate BDI with
> > > nr_wb_ctx = 1 for rotational disks. Hope this is a viable solution for
> > > spinning disks?
> > 
> > Sounds good to me, spinning rust isn't known for iops.
> > 
> > Though: What about a raid0 of spinning rust?  Do you see the same
> > declines for sequential IO?
> 
> Well, even for a raid0 multiple I/O streams will degrade performance
> on a disk.  Of course many real life workloads will have multiple
> I/O streams anyway.
> 
> I think the important part is to have:
> 
>  a) sane defaults
>  b) an easy way for the file system and/or user to override the default
> 
> For a) a single thread for rotational is a good default.  For file system
> that driver multiple spindles independently or do compression multiple
> threads might still make sense.
> 
> For b) one big issue is that right now the whole writeback handling is
> per-bdi and not per superblock.  So maybe the first step needs to be
> to move the writeback to the superblock instead of bdi?  If someone
> uses partitions and multiple file systems on spinning rusts these
> days reducing the number of writeback threads isn't really going to
> save their day either.

We have had requests to move writeback infrastructure to be per sb in the
past, mostly so that the filesystem has a better control of the writeback
process (e.g. selection of inodes etc.). After some thought I tend to agree
that today setups where we have multiple filesystems over the same bdi and
end up doing writeback from several of them in parallel should be mostly
limited to desktops / laptops / small servers. And there you usually have
only one main data filesystem - e.g. /home/ - and you don't tend to write
that much to your / filesystem. Although there could be exceptions like
large occasional writes to /tmp, news server updates or similar. Anyway in
these cases I'd expect IO scheduler (BFQ for rotational disks where this
really matters) to still achieve a decent IO locality but it would be good
to verify what the impact is.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR