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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241007163609.fkwiybr3nnw7utnc@quack3>
Date: Mon, 7 Oct 2024 18:36:09 +0200
From: Jan Kara <jack@...e.cz>
To: Tang Yizhou <yizhou.tang@...pee.com>
Cc: jack@...e.cz, hch@...radead.org, willy@...radead.org,
	akpm@...ux-foundation.org, chandan.babu@...cle.com,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-xfs@...r.kernel.org
Subject: Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with
 the writeback code

On Sun 06-10-24 23:28:49, Tang Yizhou wrote:
> From: Tang Yizhou <yizhou.tang@...pee.com>
> 
> 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...

								Honza

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