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/
pgpUNyrXspuZc.pgp
Description: PGP signature