On Wed, 16 Jul 2008 17:23:45 +0200
Goswin von Brederlow <goswin-v-b@xxxxxx> wrote:
> "Jose R. Santos" <jrs@xxxxxxxxxx> writes:
>
> > On Wed, 16 Jul 2008 15:52:01 +0200
> > Goswin von Brederlow <goswin-v-b@xxxxxx> wrote:
> >> My test device is exactly 32 TiB large and gives the following:
> >>
> >> root@beo-13:~# LD_LIBRARY_PATH=/tmpa/ext4 /tmpa/ext4/mke2fs -T ext4dev
> >> -j -m0 /dev/mapper/ext4
> >> mke2fs 1.41.0 (10-Jul-2008)
> >> mke2fs: inode_size (256) * inodes_count (0) too big for a
> >> filesystem with 0 blocks, specify higher inode_ratio (-i)
> >> or lower inode count (-N).
> >
> > hehe, I put a FIXME-64 around this since I knew it was going to be a
> > problem. I just wasn't sure what was the right approach for fixing.
> > You'll have to specify an inode count for now.
> >
> > The "filesystem with 0 blocks" surprise me though. Looks like I missed
> > something somewhere.
>
> /*
> * Set the fs block count
> */
> void ext2fs_blocks_count_set(struct ext2_super_block *super, blk64_t blk)
> {
> super->s_blocks_count = blk;
> if (super->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT)
> super->s_blocks_count_hi = (__u64) blk >> 32;
> }
>
> EXT4_FEATURE_INCOMPAT_64BIT is not set so the upper bits just get
> ignored.
>
> MfG
> Goswin
>
> PS: Should functions that chop off upper bits like that make sure they
> are 0?
I think this is something that need to be cheched at fsck since having
these be non-zero on a non-64-bit FS should be pointing to file system
corruption. Not sure if its something that need to be done every time
we set a value on the lower bit only though.
We could add error code here but that means that the users of the
routine need to handle the error code. Determining now if we need to
return errcode_t here now would avoid the need to change the API later.
Ted. Any comment on this one?
-JRS
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
