Re: [PATCH 00/13] Parallelizing filesystem writeback

[Christoph Hellwig <hch@lst.de>]

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.

> Used PMEM of 6G

battery/capacitor backed DRAM, or optane?

>
> and NVMe SSD of 3.84 TB

Consumer drive, enterprise drive?

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