[PATCH v3] common/rc: add _require_blocks_in_file helper

[PATCH v3] common/rc: add _require_blocks_in_file helper

[Joanne Chang]

generic/735 attempts to create a file with nearly 2^32 blocks. However,
some filesystems have a maximum file block limit below this threshold.
For instance, F2FS is limited to approximately 2^30 blocks due to the
capacity of the inode. So add _require_blocks_in_file helper to skip the
test in such cases.

The helper uses a hardcoded constant instead of a programmatic method,
so that bugs which affect the maximum file size are not masked.

Signed-off-by: Joanne Chang <joannechien@google.com>
---
v2 -> v3: 
- added explanation for using constants to commit message

v1 -> v2:
- changed title from "generic/735: disable for f2fs"
- used a new helper function instead of _exclude_fs as Christoph Hellwig
  suggested

 common/rc         | 16 ++++++++++++++++
 tests/generic/735 |  1 +
 2 files changed, 17 insertions(+)

diff --git a/common/rc b/common/rc
index c3cdc220..e92f4854 100644
--- a/common/rc
+++ b/common/rc
@@ -6120,6 +6120,22 @@ _require_file_attr_special()
 	fi
 }
 
+# Require filesystem to accomodate enough blocks in a file
+_require_blocks_in_file()
+{
+	local blocks=$1
+
+	case $FSTYP in
+	f2fs)
+		if [ $blocks -gt 1057053439 ]; then
+			_notrun "$blocks blocks per file not supported on $FSTYP"
+		fi
+		;;
+	*)
+		;;
+	esac
+}
+
 ################################################################################
 # make sure this script returns success
 /bin/true
diff --git a/tests/generic/735 b/tests/generic/735
index 9bbdf3a1..2fbf125c 100755
--- a/tests/generic/735
+++ b/tests/generic/735
@@ -22,6 +22,7 @@ fi
 _require_odirect
 _require_xfs_io_command "falloc"
 _require_xfs_io_command "finsert"
+_require_blocks_in_file $(( (1 << 32) - 1 ))
 
 dev_size=$((80 * 1024 * 1024))
 _scratch_mkfs_sized $dev_size >>$seqres.full 2>&1
-- 
2.52.0.351.gbe84eed79e-goog

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Darrick J. Wong]

On Thu, Jan 08, 2026 at 02:25:01AM +0000, Joanne Chang wrote:
> generic/735 attempts to create a file with nearly 2^32 blocks. However,
> some filesystems have a maximum file block limit below this threshold.
> For instance, F2FS is limited to approximately 2^30 blocks due to the
> capacity of the inode. So add _require_blocks_in_file helper to skip the
> test in such cases.
> 
> The helper uses a hardcoded constant instead of a programmatic method,
> so that bugs which affect the maximum file size are not masked.

Not to mention trying to create a file with 1,057,053,439 blocks
allocated to it would probably take forever.

Hang on, we're talking about iblocks (aka the number of blocks allocated
to this inode), not the maximum file size in blocks, right?

If so, then maybe this function and its comments should
s/blocks/iblocks/?  Or am I confused? ;)

--D

> Signed-off-by: Joanne Chang <joannechien@google.com>
> ---
> v2 -> v3: 
> - added explanation for using constants to commit message
> 
> v1 -> v2:
> - changed title from "generic/735: disable for f2fs"
> - used a new helper function instead of _exclude_fs as Christoph Hellwig
>   suggested
> 
>  common/rc         | 16 ++++++++++++++++
>  tests/generic/735 |  1 +
>  2 files changed, 17 insertions(+)
> 
> diff --git a/common/rc b/common/rc
> index c3cdc220..e92f4854 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -6120,6 +6120,22 @@ _require_file_attr_special()
>  	fi
>  }
>  
> +# Require filesystem to accomodate enough blocks in a file
> +_require_blocks_in_file()
> +{
> +	local blocks=$1
> +
> +	case $FSTYP in
> +	f2fs)
> +		if [ $blocks -gt 1057053439 ]; then
> +			_notrun "$blocks blocks per file not supported on $FSTYP"
> +		fi
> +		;;
> +	*)
> +		;;
> +	esac
> +}
> +
>  ################################################################################
>  # make sure this script returns success
>  /bin/true
> diff --git a/tests/generic/735 b/tests/generic/735
> index 9bbdf3a1..2fbf125c 100755
> --- a/tests/generic/735
> +++ b/tests/generic/735
> @@ -22,6 +22,7 @@ fi
>  _require_odirect
>  _require_xfs_io_command "falloc"
>  _require_xfs_io_command "finsert"
> +_require_blocks_in_file $(( (1 << 32) - 1 ))
>  
>  dev_size=$((80 * 1024 * 1024))
>  _scratch_mkfs_sized $dev_size >>$seqres.full 2>&1
> -- 
> 2.52.0.351.gbe84eed79e-goog
> 
> 

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Joanne Chang]

On Sat, Jan 10, 2026 at 9:38 AM Darrick J. Wong <djwong@kernel.org> wrote:
> On Thu, Jan 08, 2026 at 02:25:01AM +0000, Joanne Chang wrote:
> > generic/735 attempts to create a file with nearly 2^32 blocks. However,
> > some filesystems have a maximum file block limit below this threshold.
> > For instance, F2FS is limited to approximately 2^30 blocks due to the
> > capacity of the inode. So add _require_blocks_in_file helper to skip the
> > test in such cases.
> >
> > The helper uses a hardcoded constant instead of a programmatic method,
> > so that bugs which affect the maximum file size are not masked.
>
> Not to mention trying to create a file with 1,057,053,439 blocks
> allocated to it would probably take forever.
>
> Hang on, we're talking about iblocks (aka the number of blocks allocated
> to this inode), not the maximum file size in blocks, right?
>
> If so, then maybe this function and its comments should
> s/blocks/iblocks/?  Or am I confused? ;)
>
> --D

If I understand correctly, generic/735 creates a large logical file, but
the actual physical block allocation is much smaller. Also, the F2FS
limitation is about how many blocks the inode can address, no matter if
the blocks are actually allocated.

So I believe the requirement is about the maximum file size in blocks,
not the number of blocks actually allocated. Does it make sense to keep
the name, or do you think another term would be clearer? I appreciate
your thoughts on this.

Best regards,
Joanne

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Chao Yu]

On 1/8/2026 10:25 AM, Joanne Chang wrote:
> generic/735 attempts to create a file with nearly 2^32 blocks. However,
> some filesystems have a maximum file block limit below this threshold.
> For instance, F2FS is limited to approximately 2^30 blocks due to the
> capacity of the inode. So add _require_blocks_in_file helper to skip the
> test in such cases.
> 
> The helper uses a hardcoded constant instead of a programmatic method,
> so that bugs which affect the maximum file size are not masked.
> 
> Signed-off-by: Joanne Chang <joannechien@google.com>

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

Thanks,

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Zorro Lang]

On Mon, Jan 12, 2026 at 11:20:36AM +0800, Joanne Chang wrote:
> On Sat, Jan 10, 2026 at 9:38 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > On Thu, Jan 08, 2026 at 02:25:01AM +0000, Joanne Chang wrote:
> > > generic/735 attempts to create a file with nearly 2^32 blocks. However,
> > > some filesystems have a maximum file block limit below this threshold.
> > > For instance, F2FS is limited to approximately 2^30 blocks due to the
> > > capacity of the inode. So add _require_blocks_in_file helper to skip the
> > > test in such cases.
> > >
> > > The helper uses a hardcoded constant instead of a programmatic method,
> > > so that bugs which affect the maximum file size are not masked.
> >
> > Not to mention trying to create a file with 1,057,053,439 blocks
> > allocated to it would probably take forever.
> >
> > Hang on, we're talking about iblocks (aka the number of blocks allocated
> > to this inode), not the maximum file size in blocks, right?
> >
> > If so, then maybe this function and its comments should
> > s/blocks/iblocks/?  Or am I confused? ;)
> >
> > --D
> 
> If I understand correctly, generic/735 creates a large logical file, but
> the actual physical block allocation is much smaller. Also, the F2FS
> limitation is about how many blocks the inode can address, no matter if
> the blocks are actually allocated.
> 
> So I believe the requirement is about the maximum file size in blocks,
> not the number of blocks actually allocated. Does it make sense to keep
> the name, or do you think another term would be clearer? I appreciate
> your thoughts on this.

Hi Darrick,

I think Joanne's explanation makes sense, if you don't have more review points
on it, I'll merge this patch.

Thanks,
Zorro

> 
> Best regards,
> Joanne
> 

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Darrick J. Wong]

On Mon, Feb 09, 2026 at 03:50:43AM +0800, Zorro Lang wrote:
> On Mon, Jan 12, 2026 at 11:20:36AM +0800, Joanne Chang wrote:
> > On Sat, Jan 10, 2026 at 9:38 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > > On Thu, Jan 08, 2026 at 02:25:01AM +0000, Joanne Chang wrote:
> > > > generic/735 attempts to create a file with nearly 2^32 blocks. However,
> > > > some filesystems have a maximum file block limit below this threshold.
> > > > For instance, F2FS is limited to approximately 2^30 blocks due to the
> > > > capacity of the inode. So add _require_blocks_in_file helper to skip the
> > > > test in such cases.
> > > >
> > > > The helper uses a hardcoded constant instead of a programmatic method,
> > > > so that bugs which affect the maximum file size are not masked.
> > >
> > > Not to mention trying to create a file with 1,057,053,439 blocks
> > > allocated to it would probably take forever.
> > >
> > > Hang on, we're talking about iblocks (aka the number of blocks allocated
> > > to this inode), not the maximum file size in blocks, right?
> > >
> > > If so, then maybe this function and its comments should
> > > s/blocks/iblocks/?  Or am I confused? ;)
> > >
> > > --D
> > 
> > If I understand correctly, generic/735 creates a large logical file, but
> > the actual physical block allocation is much smaller. Also, the F2FS
> > limitation is about how many blocks the inode can address, no matter if
> > the blocks are actually allocated.
> > 
> > So I believe the requirement is about the maximum file size in blocks,
> > not the number of blocks actually allocated. Does it make sense to keep
> > the name, or do you think another term would be clearer? I appreciate
> > your thoughts on this.
> 
> Hi Darrick,
> 
> I think Joanne's explanation makes sense, if you don't have more review points
> on it, I'll merge this patch.

Agpgth, I didn't notice this reply!  My apologies! :(

Ok, since this is a limit on the maximum logical file block number,
_require_max_file_range_blocks, perhaps?

--D

> 
> Thanks,
> Zorro
> 
> > 
> > Best regards,
> > Joanne
> > 
> 

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Zorro Lang]

On Sun, Feb 08, 2026 at 05:53:26PM -0800, Darrick J. Wong wrote:
> On Mon, Feb 09, 2026 at 03:50:43AM +0800, Zorro Lang wrote:
> > On Mon, Jan 12, 2026 at 11:20:36AM +0800, Joanne Chang wrote:
> > > On Sat, Jan 10, 2026 at 9:38 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > > > On Thu, Jan 08, 2026 at 02:25:01AM +0000, Joanne Chang wrote:
> > > > > generic/735 attempts to create a file with nearly 2^32 blocks. However,
> > > > > some filesystems have a maximum file block limit below this threshold.
> > > > > For instance, F2FS is limited to approximately 2^30 blocks due to the
> > > > > capacity of the inode. So add _require_blocks_in_file helper to skip the
> > > > > test in such cases.
> > > > >
> > > > > The helper uses a hardcoded constant instead of a programmatic method,
> > > > > so that bugs which affect the maximum file size are not masked.
> > > >
> > > > Not to mention trying to create a file with 1,057,053,439 blocks
> > > > allocated to it would probably take forever.
> > > >
> > > > Hang on, we're talking about iblocks (aka the number of blocks allocated
> > > > to this inode), not the maximum file size in blocks, right?
> > > >
> > > > If so, then maybe this function and its comments should
> > > > s/blocks/iblocks/?  Or am I confused? ;)
> > > >
> > > > --D
> > > 
> > > If I understand correctly, generic/735 creates a large logical file, but
> > > the actual physical block allocation is much smaller. Also, the F2FS
> > > limitation is about how many blocks the inode can address, no matter if
> > > the blocks are actually allocated.
> > > 
> > > So I believe the requirement is about the maximum file size in blocks,
> > > not the number of blocks actually allocated. Does it make sense to keep
> > > the name, or do you think another term would be clearer? I appreciate
> > > your thoughts on this.
> > 
> > Hi Darrick,
> > 
> > I think Joanne's explanation makes sense, if you don't have more review points
> > on it, I'll merge this patch.
> 
> Agpgth, I didn't notice this reply!  My apologies! :(
> 
> Ok, since this is a limit on the maximum logical file block number,
> _require_max_file_range_blocks, perhaps?

Thanks Darrick! I'm good with this, if Joanne agrees with this too, I can help to
make this change locally to avoid asking for a new patch.

Thanks,
Zorro

> 
> --D
> 
> > 
> > Thanks,
> > Zorro
> > 
> > > 
> > > Best regards,
> > > Joanne
> > > 
> > 
> 

Re: [PATCH v3] common/rc: add _require_blocks_in_file helper

[Joanne Chang]

On Mon, Feb 9, 2026 at 11:54 AM Zorro Lang <zlang@redhat.com> wrote:
> On Sun, Feb 08, 2026 at 05:53:26PM -0800, Darrick J. Wong wrote:
> > Ok, since this is a limit on the maximum logical file block number,
> > _require_max_file_range_blocks, perhaps?
>
> Thanks Darrick! I'm good with this, if Joanne agrees with this too, I can help to
> make this change locally to avoid asking for a new patch.
>

I agree too. Thanks Darrick for the suggestion, and thanks Zorro
for your help.

Best regards,
Joanne

> Thanks,
> Zorro
>
> >
> > --D