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

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