Hi, On Fri, 2005-02-11 at 21:27, Andreas Dilger wrote:
> > Trouble is, that limit *should* be an i_blocks limit, because i_blocks > > is still 32-bits, and (more importantly) is multiplied by the fs > > blocksize / 512 in stat(2) to return st_blocks in 512-byte chunks. > > Overflow 2^32 sectors in i_blocks and stat(2) wraps. > > I agree. The problem AFAIR is that the i_blocks accounting is done in > the quota code, so it was a challenge to get it right, and the i_size > limit was easier to do. The i_size limit is also wrong for dense files; I'd be satisfied with just getting it right! i_blocks handling through the quota calls is cleaner these days, but I don't think that's a particularly satisfactory solution --- reaching maximum file size has all sorts of specific semantics such as sending SIGXFSZ which you don't really want to have to replicate. > Until now I don't think anyone has created > dense 2TB files, so the sparse limit was enough. Yep. > Note also that there was a patch to extend i_blocks floating around > (pretty small hack to use one of the reserved fields), and it might make > sense to get this into the kernel before we actually need it. True, but it's not really a problem right now --- 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. > > if (res > (512LL << 32) - (1 << bits)) > > res = (512LL << 32) - (1 << bits); > > So, for the quick fix we could reduce this by the number of expected > [td]indirect blocks and submit that to 2.4 also. Agreed. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
