> Hi all,
>
> I found a problem at stat64 on 32bit architecture.
>
> When I called stat64 for a file which is larger than 2TB, stat64
> returned an invalid number of blocks at st_blocks on 32bit
> architecture, although it returned a valid number of blocks on 64bit
> architecture(ia64).
For jfs, it's a bigger problem than just stat64. When writing the inode
to disk, jfs calculates the number of blocks from the 32-bit value:
dip->di_nblocks = cpu_to_le64(PBLK2LBLK(ip->i_sb, ip->i_blocks))
So it won't only report the wrong number of blocks, but it will actually
store the wrong number. :-(
2. Change the type of architecture dependent stat64.st_blocks in
include/asm/asm-*/stat.h from unsigned long to unsigned long long.
I tried modifying only stat64 of 32bit architecture
(include/asm-i386/stat.h).
This changes the API, but the structure does suggest that the 4-byte pad
should be used for the high-order bytes of st_blocks, so that's not
really a problem. A correct fix would replace __pad4 with
st_blocks_high (or something like that) and ensure that the high-order
word was stored there. Your proposed fix would only be correct on
little-endian hardware, as Jörn pointed out.