On Mon, Jan 13, 2025 at 10:35:17AM -0800, Darrick J. Wong wrote:
>
> Hmm -- num_blocks is ... the number of "extent records", right? And on
> a !extents file, each block mapped by an {in,}direct block counts as a
> separate "extent record", right?
>
> In that case, I think (1U<<31) isn't quite right, because the very large
> file could have an ACL block, or (shudder) a "hurd translator block".
> So that's (1U<<31) + 2 for !extents files.
>
> For extents files, shouldn't this be (1U<<48) + 2? Since you /could/
> create a horrifingly large extent tree with a hojillion little
> fragments, right? Even if it took a million years to create such a
> monster? :)
The code paths in question are only used for indirect mapped files.
The logic for handling extent-mapped files is check_blocks_extents()
in modern versions of e2fsprogs, which is why Catalin was only seeing
this for an ext3 file systems that had huge_file enabled.
You're right though that we shouldn't be using num_blocks at all for
testing for regular files or directory files that are too big, since
num_blocks include blocks for extended attribute blocks, the
ind/dind/tind blocks, etc. We do care about num_blocks being too big
for the !huge_file case since for !huge_file file systems i_blocks is
denominated in 512 byte units, and is only 32-bits wide. So in that
case, we *do* care about the size of the file including metadata
blocks being no more than 2TiB.
- Ted
