[PATCH] generic/064: allow 50 extents on F2FS after fcollapse

[PATCH] generic/064: allow 50 extents on F2FS after fcollapse

[Jan Prusakowski]

On F2FS, generic/064 fails with "extents mismatched before = 1 after =
50" following multiple fcollapse (collapse range) operations.

To ensure crash consistency and checkpoint integrity, F2FS forbids
in-place SSR (Summary Standalone Replacement) overwrites on valid
checkpointed blocks. When collapse range shifts blocks, F2FS allocates
new data pages in LFS mode (out-of-place log writes). As a result,
sequential collapse range calls rewrite shifted blocks at new log
locations, intentionally leaving the file with 50 extents.

Adjust the extent verification in generic/064 to expect exactly 50
extents on F2FS, while preserving the strict 1-extent requirement for
all other filesystems. Data integrity continues to be verified via byte
comparison.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
---
 tests/generic/064 | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/generic/064 b/tests/generic/064
index aed13970..b77eccb4 100755
--- a/tests/generic/064
+++ b/tests/generic/064
@@ -59,7 +59,13 @@ for (( j=0; j < $(($BLOCKS/2)); j++ )); do
 done
 
 extent_after=`_count_extents $dest`
-if [ $extent_before -ne $extent_after ]; then
+
+if [ "$FSTYP" == "f2fs" ];
+then
+	if [ $extent_before -ne 1 ] || [ $extent_after -ne 50 ]; then
+		echo "extents mismatched before = $extent_before after = $extent_after"
+	fi
+elif [ $extent_before -ne $extent_after ]; then
 	echo "extents mismatched before = $extent_before after = $extent_after"
 fi
 
-- 
2.55.0.rc0.786.g65d90a0328-goog

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

[Chao Yu]

On 6/22/26 15:04, Jan Prusakowski via Linux-f2fs-devel wrote:
> On F2FS, generic/064 fails with "extents mismatched before = 1 after =
> 50" following multiple fcollapse (collapse range) operations.
> 
> To ensure crash consistency and checkpoint integrity, F2FS forbids
> in-place SSR (Summary Standalone Replacement) overwrites on valid
> checkpointed blocks. When collapse range shifts blocks, F2FS allocates
> new data pages in LFS mode (out-of-place log writes). As a result,
> sequential collapse range calls rewrite shifted blocks at new log
> locations, intentionally leaving the file with 50 extents.
> 
> Adjust the extent verification in generic/064 to expect exactly 50
> extents on F2FS, while preserving the strict 1-extent requirement for
> all other filesystems. Data integrity continues to be verified via byte
> comparison.
> 
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

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

[Christoph Hellwig]

On Mon, Jun 22, 2026 at 07:04:38AM +0000, Jan Prusakowski wrote:
> On F2FS, generic/064 fails with "extents mismatched before = 1 after =
> 50" following multiple fcollapse (collapse range) operations.
> 
> To ensure crash consistency and checkpoint integrity, F2FS forbids
> in-place SSR (Summary Standalone Replacement) overwrites on valid
> checkpointed blocks. When collapse range shifts blocks, F2FS allocates
> new data pages in LFS mode (out-of-place log writes). As a result,
> sequential collapse range calls rewrite shifted blocks at new log
> locations, intentionally leaving the file with 50 extents.

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.

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

[Zorro Lang]

On Wed, Jun 24, 2026 at 12:46:01AM -0700, Christoph Hellwig wrote:
> On Mon, Jun 22, 2026 at 07:04:38AM +0000, Jan Prusakowski wrote:
> > On F2FS, generic/064 fails with "extents mismatched before = 1 after =
> > 50" following multiple fcollapse (collapse range) operations.
> > 
> > To ensure crash consistency and checkpoint integrity, F2FS forbids
> > in-place SSR (Summary Standalone Replacement) overwrites on valid
> > checkpointed blocks. When collapse range shifts blocks, F2FS allocates
> > new data pages in LFS mode (out-of-place log writes). As a result,
> > sequential collapse range calls rewrite shifted blocks at new log
> > locations, intentionally leaving the file with 50 extents.
> 
> 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?

> 

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

[Chao Yu]

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.

Thanks,

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

[Zorro Lang]

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,

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

[Christoph Hellwig]

On Tue, Jun 30, 2026 at 08:09:19PM +0800, Chao Yu wrote:
> 
> 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.

So looking at this explanation and the code, f2fs does not actually
support COLLAPSE_RANGE at all, but emulates by doing a full data
copy.  What is the point of this and lying to the user that it supports
and operation that isn't actually supported as the intended metadata
only swizzle?

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

[Chao Yu]

Hi Christoph,

On 7/20/26 16:04, Christoph Hellwig wrote:
> So looking at this explanation and the code, f2fs does not actually
> support COLLAPSE_RANGE at all, but emulates by doing a full data

For non-checkpoint data, we can just update metadata w/o any data copying
to support COLLAPSE_RANGE.

> copy.  What is the point of this and lying to the user that it supports
> and operation that isn't actually supported as the intended metadata
> only swizzle?

I added the fcollapse support long time ago in commit b4ace3370324
("f2fs: support FALLOC_FL_COLLAPSE_RANGE"), and then, a following patch
was committed to fix checkpoint case by copying data.

IIRC, the intention at that time is trying to support modern filesystem
features as many as possible, so while commercializing f2fs filesystem,
it won't break userspace application use if previous filesystem support
the feature.

I just followed manual of fallocate 2 to implement the fcollapse, I didn't
notice fcollapse is a metadata operation only interface, but I may missed
something in manual or discussion conclusion about fcollapse in community,
please let me know if I missed something. :)

Thanks,

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

[Chao Yu]

Hi Zorro,

On 7/19/2026 5:24 PM, Zorro Lang wrote:
> 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.

It makes sense to me, we can discuss about the detailed implementation in f2fs
list if there is any concern.

> 
> 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.

Looks good, thanks for the help!

Thanks

> 
> Thanks,
> Zorro
> 
>>
>> Thanks,

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

[Christoph Hellwig]

On Wed, Jul 22, 2026 at 09:12:48AM +0800, Chao Yu wrote:
> Hi Christoph,
> 
> On 7/20/26 16:04, Christoph Hellwig wrote:
> > So looking at this explanation and the code, f2fs does not actually
> > support COLLAPSE_RANGE at all, but emulates by doing a full data
> 
> For non-checkpoint data, we can just update metadata w/o any data copying
> to support COLLAPSE_RANGE.

Can you clarify what "non-checkpoint data" data means?  Older data?

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

[Chao Yu]

On 7/22/26 16:59, Christoph Hellwig wrote:
> Can you clarify what "non-checkpoint data" data means?  Older data?

It is newer data.

1. write data first, and then trigger checkpoint, after checkpoint, data will
become checkpointed one, for such case we can only collapse w/ data copying.
2. write data (data is non-checkpointed if there is no following checkpoint),
then we can collapse w/ metadata update.