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

[Stephen C. Tweedie]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/