Re: Ext2/3 32-bit stat() wrap for ~2TB files

[Andreas Dilger <adilger@clusterfs.com>]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Feb 11, 2005  21:39 +0000, Stephen C. Tweedie wrote:
> ...i_blocks is counted in fs blocksize units, so we're nowhere near
> overflowing that.  It's only when stat() converts it to st_blocks'
> 512-byte units that we get into trouble within the kernel.

Umm, I don't think so.  ext3 i_blocks is sectors and not fs blocks (one of
my pet peeves actually).  In 2.4 it is as below, 2.6 has one more copy.

ext3_read_inode()
{
	:
	inode->i_blocks = le32_to_cpu(raw_inode->i_blocks);

cp_new_stat()
{
	:
	tmp.st_blocks = inode->i_blocks;


I've wondered at times whether it might make sense to store i_blocks in
fs blocksize units when we add some new feature (e.g. high bits for
i_blocks if we overflow 2^32) but I'm not sure the increased complexity
makes up for the minor increase in dynamic range.

In the end, we hit the 2^64 fs size limit before we would run out of
range for i_blocks (assuming 64 bits there) so changing it doesn't help
much.  The only reason to change would be to store up to 2^48 fs blocks
(only using 16 bits in the core inode, e.g. i_frag + i_fsize) and assume
we need to use 2^16 blocksize for the largest files with extents.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]