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] [day] [month] [year] [list]
Message-ID: <643e61a6-3539-492d-89d0-6e0ad918eccf@kernel.org>
Date: Tue, 20 Jan 2026 20:49:11 +0800
From: Chao Yu <chao@...nel.org>
To: Nanzhe Zhao <nzzhao@....com>
Cc: chao@...nel.org, jaegeuk@...nel.org, linux-kernel@...r.kernel.org,
 linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid f2fs_map_blocks() for consecutive
 holes in readpages

Nanzhe,

On 1/20/2026 8:24 AM, Nanzhe Zhao wrote:
> Hi Chao:
> At 2026-01-19 21:44:48, "Chao Yu" <chao@...nel.org> wrote:
>>
>> I guess f2fs_map_no_dnode() will update map->m_next_pgofs to pgofs of next
>> potential valid dnode.
>>
>> Thanks,
>>
> 
> I guess we were discussing the cases that f2fs_get_dnode_of_data won't return
> -ENOENT in f2fs_map_blocks but dn.blkaddr is still NULL_ADDR or NEW_ADDR ?

I may misunderstand your question at first place, sorry about that.

> 
> I think I might understand the intention behind your repeated emphasis on the
> f2fs_map_no_dnode case?  Are you saying that, on F2FS, the vast majority of sparse
> files fall into holes where the dnode hasn't been allocated at all, and that within the
> dnode the blkaddr values NULL_ADDR and NEW_ADDR—especially the latter on the read path
> —are relatively uncommon?

Actually, no, we'd better investigate into details of hole data pattern in device
to see whether there are 1) more small holes in dnode (NULL_ADDR/NEW_ADDR case) or
2) there are more large hole in {di,i}dnode, do you have free slot to check that? :)

Thanks,

> 
> Thanks,
> Nanzhe Zhao


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ