Re: [PATCH v4 2/7] hfsplus: rework hfsplus_get_block() logic

[Viacheslav Dubeyko]

On Mon, 2026-09-14 at 19:34 -0700, Darrick J. Wong wrote:
> On Mon, Sep 14, 2026 at 04:39:36PM -0700, Viacheslav Dubeyko wrote:
> > Split the extent-lookup/allocate logic out of hfsplus_get_block()
> > into
> > a new hfsplus_map_extent(), which reports the mapping as
> > (dblock, max_blocks, balloc) instead of filling in a buffer_head.
> > hfsplus_get_block() becomes a thin wrapper around it for the
> > buffer_head-based callers (B-tree metadata, symlinks).
> > 
> > No functional change to the existing buffer_head path. This is
> > preparation for the iomap-based regular file I/O path added in a
> > later patch, which will call hfsplus_map_extent() directly.
> > 
> > cc: Christoph Hellwig <hch@xxxxxx>
> > cc: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
> > cc: Yangtao Li <frank.li@xxxxxxxx>
> > cc: linux-fsdevel@xxxxxxxxxxxxxxx
> > Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> > Signed-off-by: Viacheslav Dubeyko <slava@xxxxxxxxxxx>
> > ---
> >  fs/hfsplus/extents.c    | 118 +++++++++++++++++++++++++++++-------
> > ----
> >  fs/hfsplus/hfsplus_fs.h |   2 +
> >  2 files changed, 87 insertions(+), 33 deletions(-)
> > 
> > diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
> > index eb7c11524d18..ffd52ad8867c 100644
> > --- a/fs/hfsplus/extents.c
> > +++ b/fs/hfsplus/extents.c
> > @@ -48,18 +48,29 @@ static void
> > hfsplus_ext_build_key(hfsplus_btree_key *key, u32 cnid,
> >  	key->ext.pad = 0;
> >  }
> >  
> > -static u32 hfsplus_ext_find_block(struct hfsplus_extent *ext, u32
> > off)
> > +/*
> > + * hfsplus_ext_find_block() - find contiguous sequence of block
> > + *
> > + * Find the disk allocation block for 'off' within an 8-entry
> > + * extent record, and the number of further allocation blocks
> > + * that are contiguous with it in the same extent entry.
> > + */
> > +static u32 hfsplus_ext_find_block(struct hfsplus_extent *ext, u32
> > off,
> > +				 u32 *dblock)
> 
> Hmm.  Does this function take an hfs+ extent and a file block offset
> within that extent as inputs?  And are its outputs the physical block
> number in @dblock, and the block count as the return value?
> 
> (Wow, TN1150 is still available!)
> 
> It's sorta too bad that this code doesn't just return a mapping
> structure with some nice names to make the code easier to understand,
> but, eh, whatever.  Old fs code isn't always pretty. :)
> 
> This took me a while to understand, but it seems reasonable to me so
> Acked-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
> 

Yeah, I agree that it requires to have more nice refactoring. :) But
it's too many places in HFS+ that requires of this. So, small step at
once. :)

Thanks,
Slava.