should ext2fs_get_device_size() be returning EFBIG for >8T (or 16T?)

should ext2fs_get_device_size() be returning EFBIG for >8T (or 16T?)

[Eric Sandeen]

I have a bug saying hey, I can't grow my filesystem on a 16T device, and
it's because really we can only go to (2^32)-1 blocks, not (2^32)...

I was going to just silently round down by a block, because for example
LVM makes it *very* easy to make exactly 16T devices; dropping a block
at mkfs/growfs time seems reasonable to me.

So that led me to ext2fs_get_device_size, and I see it actually has the
maximum allowable filesystem size encoded in it, and you get EFBIG if
it's bigger.

I think this disallows you from being able to specify a smaller size on
the resize cmdline too; the device size check bails out before that.

I'm not sure what the plan is for size checks in the ext4 world, but it
seems to me that the device size check and the acceptable fs size checks
should be separate things.

Comments?

Thanks,
-Eric

Re: should ext2fs_get_device_size() be returning EFBIG for >8T (or 16T?)

[Eric Sandeen]

Eric Sandeen wrote:
> I have a bug saying hey, I can't grow my filesystem on a 16T device, and
> it's because really we can only go to (2^32)-1 blocks, not (2^32)...
> 
> I was going to just silently round down by a block, because for example
> LVM makes it *very* easy to make exactly 16T devices; dropping a block
> at mkfs/growfs time seems reasonable to me.
> 
> So that led me to ext2fs_get_device_size, and I see it actually has the
> maximum allowable filesystem size encoded in it, and you get EFBIG if
> it's bigger.

Actually I guess it's looking at the largest number a blk_t can hold,
but I think the same principle applies.  Maybe it's not a big deal today...

-Eric