linux-kernel - Re: [PATCH -next v2 00/22] ext4: use iomap for regular file's buffered I/O path

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aYGZB_hugPRXCiSI@infradead.org>
Date: Mon, 2 Feb 2026 22:43:19 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Zhang Yi <yi.zhang@...wei.com>
Cc: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, tytso@....edu,
	adilger.kernel@...ger.ca, jack@...e.cz, ojaswin@...ux.ibm.com,
	ritesh.list@...il.com, hch@...radead.org, djwong@...nel.org,
	yi.zhang@...weicloud.com, yizhang089@...il.com,
	libaokun1@...wei.com, yangerkun@...wei.com, yukuai@...as.com
Subject: Re: [PATCH -next v2 00/22]  ext4: use iomap for regular file's
 buffered I/O path

> Original Cover (Updated):

This really should always be first.  The updates are rather minor
compared to the overview that the cover letter provides.

> Key notes on the iomap implementations in this series.
>  - Don't use ordered data mode to prevent exposing stale data when
>    performing append write and truncating down.

I can't parse this.

>  - Override dioread_nolock mount option, always allocate unwritten
>    extents for new blocks.

Why do you override it?

>  - When performing write back, don't use reserved journal handle and
>    postponing updating i_disksize until I/O is done.

Again missing the why and the implications.

>  buffered write
>  ==============
> 
>   buffer_head:
>   bs      write cache    uncached write
>   1k       423  MiB/s      36.3 MiB/s
>   4k       1067 MiB/s      58.4 MiB/s
>   64k      4321 MiB/s      869  MiB/s
>   1M       4640 MiB/s      3158 MiB/s
>   
>   iomap:
>   bs      write cache    uncached write
>   1k       403  MiB/s      57   MiB/s
>   4k       1093 MiB/s      61   MiB/s
>   64k      6488 MiB/s      1206 MiB/s
>   1M       7378 MiB/s      4818 MiB/s

This would read better if you actually compated buffered_head
vs iomap side by side.

What is the bs?  The read unit size?  I guess not the file system
block size as some of the values are too large for that.

Looks like iomap is faster, often much faster except for the
1k cached case, where it is slightly slower.  Do you have
any idea why?

>  buffered read
>  =============
> 
>   buffer_head:
>   bs      read hole   read cache      read data
>   1k       635  MiB/s    661  MiB/s    605  MiB/s
>   4k       1987 MiB/s    2128 MiB/s    1761 MiB/s
>   64k      6068 MiB/s    9472 MiB/s    4475 MiB/s
>   1M       5471 MiB/s    8657 MiB/s    4405 MiB/s
> 
>   iomap:
>   bs      read hole   read cache       read data
>   1k       643  MiB/s    653  MiB/s    602  MiB/s
>   4k       2075 MiB/s    2159 MiB/s    1716 MiB/s
>   64k      6267 MiB/s    9545MiB/s     4451 MiB/s
>   1M       6072 MiB/s    9191MiB/s     4467 MiB/s

What is read cache vs read data here?

Otherwise same comments as for the write case.