linux-ext4 - Use case for EXT4_INODE_HUGE_FILE / EXT4_HUGE_FILE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Apr 2020 15:45:34 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     linux-ext4@...r.kernel.org
Subject: Use case for EXT4_INODE_HUGE_FILE / EXT4_HUGE_FILE_FL?

Under what circumstances can an inode ever end up with EXT4_HUGE_FILE_FL
set? (Other than in an artificially constructed filesystem.)

As far as I can tell, extents don't allow a file to get bigger than
2**32 filesystem blocks (because they store block offsets in an le32),
which with the maximum filesystem block size of 65536 would be 2**48
bytes.

That's lower than the file size limit that EXT4_HUGE_FILE_FL seems to
exist to surpass; even without EXT4_HUGE_FILE_FL, the 48-bit "block"
count in the inode would allow a file to have 2**48 512-byte "blocks" in
it, or 2**57 bytes.

Was EXT4_HUGE_FILE_FL just added for future extensibility, in case a
future file storage mechanism allows storing files bigger than 2**32
blocks?

How extensively has it been tested?

(Related: are there any plans or discussions regarding a future extent
format? Not necessarily just for that reason, but there are other limits
in the existing extent format, such as the limit of 32768 contiguous
blocks in one extent.)

Thanks,
Josh Triplett