![]() | |||||||||||
Messages in this thread |
Hi, > > 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. :-( I also found another problem on generic quota code. In dquot_transfer(), the file usage is calculated from i_blocks via inode_get_bytes(). If the file is over 2TB, the change of usage is less than expected. To solve this problem, I think inode.i_blocks should be 8 byte. >> 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. Thank you for your advice. I'll research for glibc and consider how to implement. By the way I think, as Avi Kivity said, it's always little-endian on i386, is it correct? -- Takashi Sato - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-12-02 14:20 [from the cache] ©2003-2008 | |||||||||||