Re: [PATCH 00/13] Parallelizing filesystem writeback

Darrick J. Wong
2025-06-11T15:51:45Z

On Wed, Jun 04, 2025 at 02:52:34PM +0530, Kundan Kumar wrote:
> > > > For xfs used this command:
> > > > xfs_io -c "stat" /mnt/testfile
> > > > And for ext4 used this:
> > > > filefrag /mnt/testfile
> > >
> > > filefrag merges contiguous extents, and only counts up for discontiguous
> > > mappings, while fsxattr.nextents counts all extent even if they are
> > > contiguous. So you probably want to use filefrag for both cases.
> >
> > Got it — thanks for the clarification. We'll switch to using filefrag
> > and will share updated extent count numbers accordingly.
>
> Using filefrag, we recorded extent counts on xfs and ext4 at three
> stages:
> a. Just after a 1G random write,
> b. After a 30-second wait,
> c. After unmounting and remounting the filesystem,
>
> xfs
> Base
> a. 6251 b. 2526 c. 2526
> Parallel writeback
> a. 6183 b. 2326 c. 2326

Interesting that the mapping record count goes down...

I wonder, you said the xfs filesystem has 4 AGs and 12 cores, so I guess
wb_ctx_arr[] is 12? I wonder, do you see a knee point in writeback
throughput when the # of wb contexts exceeds the AG count?

Though I guess for the (hopefully common) case of pure overwrites, we
don't have to do any metadata updates so we wouldn't really hit a
scaling limit due to ag count or log contention or whatever. Does that
square with what you see?

> ext4
> Base
> a. 7080 b. 7080 c. 11
> Parallel writeback
> a. 5961 b. 5961 c. 11

Hum, that's particularly ... interesting. I wonder what the mapping
count behaviors are when you turn off delayed allocation?

--D

> Used the same fio commandline as earlier:
> fio --filename=/mnt/testfile --name=test --bs=4k --iodepth=1024
> --rw=randwrite --ioengine=io_uring --fallocate=none --numjobs=1
> --size=1G --direct=0 --eta-interval=1 --eta-newline=1
> --group_reporting
>
> filefrag command:
> filefrag /mnt/testfile
>