Re: [f2fs-dev] [PATCH] generic/064: allow 50 extents on F2FS after fcollapse

On Tue, Jun 30, 2026 at 08:09:19PM +0800, Chao Yu wrote:
> On 6/30/26 00:37, Zorro Lang via Linux-f2fs-devel wrote:
> > On Wed, Jun 24, 2026 at 12:46:01AM -0700, Christoph Hellwig wrote:
> >> This sounds odd.  The test allocates a contigous range and then just does
> >> insert/collapse on it, which should not lead to any new data block
> >> allocations.  Given that the test works fine on zoned XFS and btrfs
> >> with strict out of place write policies we know it does not require
> >> overwriting blocks to work as well.
> >>
> >> So I think something is fishy in f2fs if needs to allocate data blocks
> >> here.
> > 
> > I have the same question with Christoph. Shouldn't fcollapse in F2FS just
> > remap the metadata instead of allocating new data blocks?
> 
> Hi Christoph, Zorro,
> 
> Let me explain it briefly, this is because f2fs has only one copy of reverse
> mapping table (aka SSA), for any checkpointed data, we can not modify SSA info
> directly during remap, otherwise, after sudden power-cut, we will suffer
> inconsistent issue in between reverse mapping table and mapping table. So, f2fs
> choose to rewrite for any checkpointed data.

Hi Chao,

Thank you for the detailed explanation. I now see why F2FS handles this
differently.

Since this is by design for F2FS, I'd like to merge this fix to help f2fs
avoid this test failure at first. As for the potential write amplification
and performance overhead introduced by this rewrite strategy, that can be
discussed further on the f2fs list if necessary.

I will merge the patch with some clarifying comments:

/*
 * F2FS uses a rewrite strategy for fcollapse/finsert on checkpointed data.
 * Since F2FS has only a single copy of the reverse mapping table (SSA),
 * directly remapping checkpointed metadata could cause inconsistency
 * issues after a sudden power-cut.
 */

Is this ^^ good to you, or feel free to give me a proper comment to add into
this patch.

Thanks,
Zorro

> 
> Thanks,