linux-ext4 - Re: [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc

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: <878qn7gogg.fsf@gmail.com>
Date: Thu, 08 May 2025 20:05:27 +0530
From: Ritesh Harjani (IBM) <ritesh.list@...il.com>
To: John Garry <john.g.garry@...cle.com>, Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>
Cc: djwong@...nel.org, Ojaswin Mujoo <ojaswin@...ux.ibm.com>, linux-ext4@...r.kernel.org
Subject: Re: [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc

John Garry <john.g.garry@...cle.com> writes:

> On 30/04/2025 06:20, Ritesh Harjani (IBM) wrote:
>> This is still an early preview (RFC v2) of multi-fsblock atomic write. Since the
>> core design of the feature looks ready, wanted to post this for some early
>> feedback. We will break this into more smaller and meaningful patches in later
>> revision. However to simplify the review of the core design changes, this
>> version is limited to just two patches. Individual patches might have more
>> details in the commit msg.
>> 
>> Note: This overall needs more careful review (other than the core design) which
>> I will be doing in parallel. However it would be helpful if one can provide any
>> feedback on the core design changes. Specially around ext4_iomap_alloc()
>> changes, ->end_io() changes and a new get block flag
>> EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS.
>
> I gave this a try and it looks ok, specifically atomic writing mixed 
> mappings.
>

Thanks John for taking a look.

> I'll try to look closer that the implementation details.

We are in the process of sending v3 (hopefully by tonight) which is an
improved version w.r.t error handling, journal credits and few other
changes. Although nothing has changed w.r.t the design aspect.

> But I do note 
> that you use blkdev_issue_zeroout() to pre-zero any unwritten range 
> which is being atomically written.

Yes, that is how internally ext4_map_blocks() with
EXT4_GET_BLOCKS_CREATE_ZERO will return us the allocated blocks. During
block allocation, on mixed mapping range, we ensure that the entire range
becomes a contiguous mapped extent before starting any data writes.
That means calling ext4_map_blocks() in a loop with
EXT4_GET_BLOCKS_CREATE_ZERO, so that it can zero out any unwritten
extents in the requested region.
I assume writing over a mixed mapping region is not a performance
critical path. 

Do you forsee any problems with the approach (since you said "But I do note...")?

-ritesh