Re: [RFC PATCH v5 3/4] ocfs2: switch dio write path from buffer_head to iomap

[Heming Zhao <heming.zhao@suse.com>]

On 11/6/26 18:52, Christoph Hellwig wrote:
> On Thu, Nov 05, 2026 at 03:19:27PM +0800, Heming Zhao wrote:
>> Converts OCFS2's DIO write path from the legacy buffer_head
>> infrastructure to the modern iomap framework.
>>
>> Key modifications and designs are as follows:
> 
> That's a not very useful style of usually AI generated text.
> 
> If a change is not key it should not be mentioned here.
> 
> As should "modifications" in general - what is changed is pretty
> obvious in the diff itself (and if it isn't it should be made more
> clear in the code/comments).  So what should go into the commit
> log really is the high-level considerations, pitfals and not quite
> clear bits.  The rest is just unhelpful noise.
> 

got your meaning, will revise the commit log.

> 
>> +static int ocfs2_lock_map_blocks(struct inode *inode,
>> +				 struct ocfs2_map_block *map, int flags)
>> +{
>> +	int ret = 0;
>> +	struct ocfs2_inode_info *oi = OCFS2_I(inode);
>> +
>> +	down_read(&oi->ip_alloc_sem);
>> +	ret = ocfs2_map_blocks(inode, map, flags);
>> +	up_read(&oi->ip_alloc_sem);
>> +
>> +	return ret;
>> +}
> 
> This pattern already showed up in the previous patch, why isn't the
> helper added there and used for reads as well?
> 
> Also this and the next one have a very similar diffstat.  It would
> help reviewers a lot if you merged the two patches and did any pure
> code movements in a separate patch, so that the actual changes stick
> out instead of just adding a wall of new code here, and removing
> lots of old code in the next one.
> 

I'll take your suggestions into account.

My intention with this layout was to let reviewers side-by-side compare what
has actually changed between the new (iomap) and old (buffer_head) paths.
Since ocfs2 involves cluster locking, and the buffer_head path has been
running stably in production for over 20 years, my current approach is to
preserve the existing buffer_head flow and logic as much as possible,
introducing only the minimal changes strictly necessary for iomap.

I plan to leverage advanced iomap features to boost DIO performance in
future work.

-Heming