Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 6 Apr 2020 15:45:34 -0700
From:   Josh Triplett <josh@joshtriplett.org>
To:     linux-ext4@vger.kernel.org
Subject: Use case for EXT4_INODE_HUGE_FILE / EXT4_HUGE_FILE_FL?
Message-ID: <20200406224534.GA668050@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

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