Hi all,

This is a follow-up to the b-tree allocator corruption fix series [1],
implementing the allocator optimization discussed during v4 review [2].

Currently, hfs_bmap_alloc() performs a first-fit linear scan starting
from bit 0 on every call, rescanning already-used regions at the front
of the bitmap. This patch converts it to a next-fit allocator by caching
the last successful allocation position in an in-core alloc_hint field.

Key changes:
- Allocation starts from alloc_hint and wraps around if needed.
- The seek to the target map node uses the hfs_bmap_get_map_page() API
  introduced in [1] for node-type validation and offset checking.
- Map chain extension (hfs_bmap_new_bmap) is checked before wrap-around,
  so nodes reserved by hfs_bmap_reserve() are always reachable.
- hfs_bmap_free() pulls alloc_hint back when a freed node is below the
  current hint.
- No on-disk format changes.

Based on the for-next branch of
https://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs.git

Testing:
- Custom stress tests covering sequential allocation, interleaved
  alloc/free, ENOSPC on small images, and remount reset
- No HFS+ warnings or errors in kernel logs

[1] https://lore.kernel.org/all/20260318073834.462702-1-shardul.b@mpiricsoftware.com/
[2] https://lore.kernel.org/all/7194aa49efdb85c7cfc9578f1460aaa9a1c67095.camel@mpiricsoftware.com/

Kalpan Jani (1):
  hfsplus: switch hfs_bmap_alloc() to next-fit allocation using
    alloc_hint

 fs/hfsplus/btree.c      | 114 +++++++++++++++++++++++++++++++++++-----
 fs/hfsplus/hfsplus_fs.h |   1 +
 2 files changed, 101 insertions(+), 14 deletions(-)

--
2.34.1

On Mon, 2026-04-06 at 11:00 +0530, Kalpan Jani wrote:
> Hi all,
> 
> This is a follow-up to the b-tree allocator corruption fix series [1],
> implementing the allocator optimization discussed during v4 review [2].
> 
> Currently, hfs_bmap_alloc() performs a first-fit linear scan starting
> from bit 0 on every call, rescanning already-used regions at the front
> of the bitmap. This patch converts it to a next-fit allocator by caching
> the last successful allocation position in an in-core alloc_hint field.
> 
> Key changes:
> - Allocation starts from alloc_hint and wraps around if needed.
> - The seek to the target map node uses the hfs_bmap_get_map_page() API
>   introduced in [1] for node-type validation and offset checking.
> - Map chain extension (hfs_bmap_new_bmap) is checked before wrap-around,
>   so nodes reserved by hfs_bmap_reserve() are always reachable.
> - hfs_bmap_free() pulls alloc_hint back when a freed node is below the
>   current hint.
> - No on-disk format changes.
> 
> Based on the for-next branch of
> https://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs.git
> 
> Testing:
> - Custom stress tests covering sequential allocation, interleaved
>   alloc/free, ENOSPC on small images, and remount reset
> - No HFS+ warnings or errors in kernel logs
> 
> [1] https://lore.kernel.org/all/20260318073834.462702-1-shardul.b@mpiricsoftware.com/
> [2] https://lore.kernel.org/all/7194aa49efdb85c7cfc9578f1460aaa9a1c67095.camel@mpiricsoftware.com/
> 
> Kalpan Jani (1):
>   hfsplus: switch hfs_bmap_alloc() to next-fit allocation using
>     alloc_hint
> 
>  fs/hfsplus/btree.c      | 114 +++++++++++++++++++++++++++++++++++-----
>  fs/hfsplus/hfsplus_fs.h |   1 +
>  2 files changed, 101 insertions(+), 14 deletions(-)
> 
> --
> 2.34.1
> 

If it's only one patch, then cover letter is not really necessary.

Thanks,
Slava.