[PATCH v1] generic/735: disable for f2fs

[PATCH v1] generic/735: disable for f2fs

[Joanne Chang]

generic/735 attempts to create a file with nearly 2^32 blocks. However,
the maximum block count per file in F2FS is limited by the capacity of
the inode. This limit is roughly 2^30 blocks, which is significantly
lower than the test's requirement.

Signed-off-by: Joanne Chang <joannechien@google.com>
---
 tests/generic/735 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/generic/735 b/tests/generic/735
index 9bbdf3a1..d5ba5673 100755
--- a/tests/generic/735
+++ b/tests/generic/735
@@ -19,6 +19,9 @@ if [[ "$FSTYP" =~ ext[0-9]+ ]]; then
 	_fixed_by_kernel_commit 2dcf5fde6dff "ext4: prevent the normalized size from exceeding EXT_MAX_BLOCKS"
 fi
 
+# Block number 0xffffffff is too big for a file in f2fs.
+_exclude_fs f2fs
+
 _require_odirect
 _require_xfs_io_command "falloc"
 _require_xfs_io_command "finsert"
-- 
2.52.0.313.g674ac2bdf7-goog

Re: [PATCH v1] generic/735: disable for f2fs

[Christoph Hellwig]

On Thu, Dec 18, 2025 at 07:17:17AM +0000, Joanne Chang wrote:
> generic/735 attempts to create a file with nearly 2^32 blocks. However,
> the maximum block count per file in F2FS is limited by the capacity of
> the inode. This limit is roughly 2^30 blocks, which is significantly
> lower than the test's requirement.
> 
> Signed-off-by: Joanne Chang <joannechien@google.com>
> ---
>  tests/generic/735 | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tests/generic/735 b/tests/generic/735
> index 9bbdf3a1..d5ba5673 100755
> --- a/tests/generic/735
> +++ b/tests/generic/735
> @@ -19,6 +19,9 @@ if [[ "$FSTYP" =~ ext[0-9]+ ]]; then
>  	_fixed_by_kernel_commit 2dcf5fde6dff "ext4: prevent the normalized size from exceeding EXT_MAX_BLOCKS"
>  fi
>  
> +# Block number 0xffffffff is too big for a file in f2fs.
> +_exclude_fs f2fs

Please don't add random file system excludes.  This should be
abstracted into a _require_max_file_size helper or similar.

Re: [PATCH v1] generic/735: disable for f2fs

[Joanne Chang]

On Thu, Dec 18, 2025 at 3:33 PM Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Dec 18, 2025 at 07:17:17AM +0000, Joanne Chang wrote:
> > generic/735 attempts to create a file with nearly 2^32 blocks. However,
> > the maximum block count per file in F2FS is limited by the capacity of
> > the inode. This limit is roughly 2^30 blocks, which is significantly
> > lower than the test's requirement.
> >
> > Signed-off-by: Joanne Chang <joannechien@google.com>
> > ---
> >  tests/generic/735 | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/tests/generic/735 b/tests/generic/735
> > index 9bbdf3a1..d5ba5673 100755
> > --- a/tests/generic/735
> > +++ b/tests/generic/735
> > @@ -19,6 +19,9 @@ if [[ "$FSTYP" =~ ext[0-9]+ ]]; then
> >       _fixed_by_kernel_commit 2dcf5fde6dff "ext4: prevent the normalized size from exceeding EXT_MAX_BLOCKS"
> >  fi
> >
> > +# Block number 0xffffffff is too big for a file in f2fs.
> > +_exclude_fs f2fs
>
> Please don't add random file system excludes.  This should be
> abstracted into a _require_max_file_size helper or similar.

Thank you for the feedback. I will implement a
_require_blocks_in_file helper in the next version. As far as I
know, there isn't a generic way to query the block number limit
across filesystems, so I plan to hardcode the known limit for
F2FS within the helper for now.

Please let me know if you have any further suggestions.

Best regards,
Joanne

Re: [PATCH v1] generic/735: disable for f2fs

[Christoph Hellwig]

On Thu, Dec 18, 2025 at 08:02:48PM +0800, Joanne Chang wrote:
> Thank you for the feedback. I will implement a
> _require_blocks_in_file helper in the next version. As far as I
> know, there isn't a generic way to query the block number limit
> across filesystems, so I plan to hardcode the known limit for
> F2FS within the helper for now.

Oh, the limits is not the file size per se, so the number of blocks?
I.e. you can have a 64-bit i_size, but if the file isn't spare it
eventually can't fill holes?  That really does seem like behavior
applications would not not expect, aka a bug.

Re: [PATCH v1] generic/735: disable for f2fs

[Joanne Chang]

On Fri, Dec 19, 2025 at 1:30 PM Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Dec 18, 2025 at 08:02:48PM +0800, Joanne Chang wrote:
> > Thank you for the feedback. I will implement a
> > _require_blocks_in_file helper in the next version. As far as I
> > know, there isn't a generic way to query the block number limit
> > across filesystems, so I plan to hardcode the known limit for
> > F2FS within the helper for now.
>
> Oh, the limits is not the file size per se, so the number of blocks?
> I.e. you can have a 64-bit i_size, but if the file isn't spare it
> eventually can't fill holes?  That really does seem like behavior
> applications would not not expect, aka a bug.

Thanks for the reply. To clarify, I meant testing the architectural
limit of blocks per file, not the current free blocks. Sorry for any
confusion in my previous reply.

The limit is indeed the maximum file size. However, since both the F2FS
file size limit and the test's requirements are calculated as
(block_number * block_size), I believe it is simpler to just test the
block number.

Best regards,
Joanne

Re: [PATCH v1] generic/735: disable for f2fs

[Christoph Hellwig]

On Fri, Dec 19, 2025 at 04:53:04PM +0800, Joanne Chang wrote:
> Thanks for the reply. To clarify, I meant testing the architectural
> limit of blocks per file, not the current free blocks. Sorry for any
> confusion in my previous reply.
> 
> The limit is indeed the maximum file size. However, since both the F2FS
> file size limit and the test's requirements are calculated as
> (block_number * block_size), I believe it is simpler to just test the
> block number.

Well, for the file size you can test by doing a truncate to the expected
size and _notrun if not supported.  I can't really think of a way that
easy to directly check for the number of supported blocks.

Re: [PATCH v1] generic/735: disable for f2fs

[Joanne Chang]

On Fri, Dec 19, 2025 at 7:10 PM Christoph Hellwig <hch@infradead.org> wrote:
> Well, for the file size you can test by doing a truncate to the expected
> size and _notrun if not supported.  I can't really think of a way that
> easy to directly check for the number of supported blocks.

I guess we can calculate the block limit by _get_max_file_size() /
block_size. However, I am concerned whether this method might mask a
regression that reduces a filesystem's supported file size. So I
wonder if explicit, hardcoded limits within the helper for known
architectural constraints (like for F2FS) would be safer, as we can
ensure tests are only skipped when the limitation is intended.

Please let me know if you have suggestions for either method.

Best regards,
Joanne