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 <[email protected]> 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 > _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
