Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 07, 2024 at 06:36:09PM +0200, Jan Kara wrote:
> On Sun 06-10-24 23:28:49, Tang Yizhou wrote:
> > From: Tang Yizhou <yizhou.tang@xxxxxxxxxx>
> > 
> > Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> > device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> > writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> > xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> > outdated.
> > 
> > In addition, Christoph mentioned that the xfs iomap process should be
> > similar to writeback, so xfs_max_map_length() was written following the
> > logic of writeback_chunk_size().
> 
> Well, I'd defer to XFS maintainers here but at least to me it does not make
> a huge amount of sense to scale mapping size with the device writeback
> throughput. E.g. if the device writeback throughput is low, it does not
> mean that it is good to perform current write(2) in small chunks...

Yeah, I was wondering if it still makes sense to throttle incoming
writes given that iomap will just call back for more mappings anyway.

--D

> 								Honza
> 
> -- 
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR
> 




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux