2010/6/22 <tytso@xxxxxxx>
>
> On Mon, Jun 21, 2010 at 09:44:31PM +0800, Hsuan-Ting wrote:
> > Hi Ted,
> >
> > Resize seems not work when the size is bigger than 16TB (offline resize).
> >
> > My test machine:
> > x64 platform 2.6.32 kernel + this newest patch
> >
> > 1. <16TB ext4 enlarge to >16TB (offline)
> > a. I use "8 x 2TB WD disks" and "mdadm" build linear raid
> > b. then use mkfs.ext4 to make ext4 file system
> > c. grow the linear raid to "10 X 2TB"
> > d. finally it grow to "2.X TB" smaller than before
>
> This doesn't surprise me. We should add some checks to simply not
> allow the file system growing greater than 16TB if the 64-bit feature
> is not set for now. Making this work is going to be tricky, because
> enabling the 64-bit feature doubles the size of the block group
> descriptors, which means we have to make room for them. This could
> involve moving files out of the way, as well as moving the inode
> table.
>
> This means that we may want to enable the 64-bit feature flag if there
> is an expectation that the filesystem might be grown to a size large
> enough where this would be an issue.
Sounds like I must enable 64-bit feature when mkfs.
Then it will work, right?
But base on my test, it will occur core dump when resize:
(gdb) bt
#0 0x00000000004160bf in ext2fs_test_bit64 ()
#1 0x0000000000416318 in ba_test_bmap ()
#2 0x0000000000410629 in ext2fs_test_generic_bmap ()
#3 0x0000000000410656 in ext2fs_test_block_bitmap_range2 ()
#4 0x000000000040873d in ext2fs_get_free_blocks2 ()
#5 0x000000000040936d in ext2fs_allocate_group_table ()
#6 0x0000000000404456 in adjust_fs_info ()
#7 0x0000000000404a81 in resize_fs ()
#8 0x00000000004069c7 in main ()
I do the following modification
(to enable "EXT4_FEATURE_INCOMPAT_64BIT" and "EXT2_FLAG_64BITS"):
misc/mke2fs.c :
@@ -1530,6 +1945,8 @@ static void PRS(int argc, char *argv[])
EXT2_BLOCK_SIZE(&fs_param));
exit(1);
}
+ fs_param.s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
ext2fs_blocks_count_set(&fs_param, fs_blocks_count);
resize/resize2fs.c :
@@ -585,6 +598,9 @@ static errcode_t adjust_superblock(ext2_resize_t
rfs, blk64_t new_size)
if (retval)
return retval;
+ fs->super->s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
retval = adjust_fs_info(fs, rfs->old_fs, rfs->reserve_blocks, new_size);
lib/ext2fs/openfs.c :
@@ -109,6 +109,8 @@ errcode_t ext2fs_open2(const char *name, const
char *io_options,
memset(fs, 0, sizeof(struct struct_ext2_filsys));
fs->magic = EXT2_ET_MAGIC_EXT2FS_FILSYS;
fs->flags = flags;
+ fs->flags |= EXT2_FLAG_64BITS;
Did I mistake something?
>
> > 2. >16TB offline resize, the steps is similiar as before.
> > a. I use "9 x 2TB WD disks" build linear raid
> > b. mkfs.ext4 and not mount
> > c. grow the linear raid to "10 X 2TB"
> > d. do resize
> > e. finally it grow to "2.X TB" smaller than before
> >
> > I try to on "EXT4_FEATURE_INCOMPAT_64BIT" and "EXT2_FLAG_64BITS"
> > when mkfs and resize.
> > And modify ext2fs_div_ceil code to ext2fs_div64_ceil.
> > It seems work something, the fs size isn't grow but also not deduce,
> > remain the same.
>
> I'm not sure I understand that last sentence; it's not parsing as an
> understandable English sentence, sorry. Are you saying that both
> attempts to grow and shrink the filesystem is failing? If so, how?
> Are you getting an error message? Is it appearing to succeed but the
> file system size isn't changing?
Sorry for my poor English. The last sentence means "succeed but the
file system size isn't changing".
I also remove "flex_bg" feature in this case.
Thanks.
-HsuanTing
>
> Thanks for the bug report,
>
> - Ted
> --
> 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
--
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
