linux-kernel - Re: Question: batching block allocation in f2fs DIO 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2c1e9438-d7db-41ce-aad8-85cede2957d4@gmail.com>
Date: Tue, 30 Dec 2025 22:25:48 +0900
From: Jeuk Kim <jeuk20.kim@...il.com>
To: Chao Yu <chao@...nel.org>, jaegeuk@...nel.org
Cc: Jinyoung Choi <j-young.choi@...sung.com>,
 Jeuk Kim <jeuk20.kim@...sung.com>, linux-kernel@...r.kernel.org,
 linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: Question: batching block allocation in f2fs DIO path


On 12/30/2025 6:27 PM, Chao Yu wrote:
> Hi Jeuk,
>
> On 12/29/2025 2:33 PM, Jeuk Kim wrote:
>> Hi F2FS maintainers,
>>
>> Sorry for the duplicate — I’m resending this because the previous
>> message was sent in HTML format.
>>
>> I’ve been looking into the DIO allocation path in f2fs, specifically
>> when a DIO write needs to allocate new blocks (e.g., hole-filling).
>>  From f2fs_map_blocks() through __allocate_data_block() →
>> f2fs_allocate_data_block(), it seems each block allocation is handled
>> one-by-one, taking curseg_lock/curseg_mutex and the SIT sentry lock
>> per block.
>>
>> I’m wondering whether batching allocations (a bounded batch, e.g., a
>> small run within the current segment) could be feasible in the DIO
>> path. My intuition is that with multiple threads doing DIO, reducing
>> per-block lock contention and improving sequentiality could help
>> throughput.
>
> I agree w/ you.
>
>>
>> Questions:
>>
>> Is there a technical or correctness reason that makes batching for DIO
>> infeasible (e.g., LFS/SSR/GC interactions, summary/SIT update
>> ordering, etc.)?
>>
>> Or is this simply an optimization that hasn’t been implemented?
>
> I've implemented a prototype of multiple block allocation for any 
> potential
> use cases: pinfile fallocation, direct IO and buffered IO. I can see 
> benefits
> from my previous test.
>
> I plan to upstream all implementations, but I think I need more time 
> to clean
> up the draft codes and check all corner cases.
>
> You can check the MBA implementation for pinfile use case in below 
> link, I
> guess this version is close to upstream.
>
> https://github.com/chaseyu/f2fs-dev/commits/feature/inbatch_write
>
> Thanks,
>
>>
>> If this seems acceptable, would you consider patches in this direction?
>>
>> If there are prior discussions or known issues on this, I’d 
>> appreciate pointers.
>>
>> Thanks for your time.
>>
>> Best regards,
>> Jeuk Kim
>

Hi Chao,

Thanks a lot for sharing this and the link.

Good to hear you’ve seen benefits from the MBA prototype.

I’ll look into the pinfile implementation and try testing it on my side.

Thanks,
Jeuk