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

[Heming Zhao]

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