Re: [PATCH 00/13] Parallelizing filesystem writeback

Anuj gupta
2025-06-03T13:52:58Z

On Tue, Jun 3, 2025 at 6:54 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Jun 03, 2025 at 02:46:20PM +0530, Anuj Gupta/Anuj Gupta wrote:
> > On 6/2/2025 7:49 PM, Christoph Hellwig wrote:
> > > On Thu, May 29, 2025 at 04:44:51PM +0530, Kundan Kumar wrote:
> > > Well, the proper thing would be to figure out a good default and not
> > > just keep things as-is, no?
> >
> > We observed that some filesystems, such as Btrfs, don't benefit from
> > this infra due to their distinct writeback architecture. To preserve
> > current behavior and avoid unintended changes for such filesystems,
> > we have kept nr_wb_ctx=1 as the default. Filesystems that can take
> > advantage of parallel writeback (xfs, ext4) can opt-in via a mount
> > option. Also we wanted to reduce risk during initial integration and
> > hence kept it as opt-in.
>
> A mount option is about the worst possible interface for behavior
> that depends on file system implementation and possibly hardware
> chacteristics. This needs to be set by the file systems, possibly
> using generic helpers using hardware information.

Right, that makes sense. Instead of using a mount option, we can
introduce generic helpers to initialize multiple writeback contexts
based on underlying hardware characteristics — e.g., number of CPUs or
NUMA topology. Filesystems like XFS and EXT4 can then call these helpers
during mount to opt into parallel writeback in a controlled way.

>
> > Used PMEM of 6G
>
> battery/capacitor backed DRAM, or optane?

We emulated PMEM using DRAM by following the steps here:
https://www.intel.com/content/www/us/en/developer/articles/training/how-to-emulate-persistent-memory-on-an-intel-architecture-server.html

>
> >
> > and NVMe SSD of 3.84 TB
>
> Consumer drive, enterprise drive?

It's an enterprise-grade drive — Samsung PM1733

>
> > 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.