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
| ||
|
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
Powered by blists - more mailing lists