Re: Can't resize2fs - combination of flex_bg and !resize_inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 21.08.2012 05:02, schrieb Theodore Ts'o:
On Mon, Aug 20, 2012 at 03:18:35AM -0400, Curtis Jones wrote:
Hi. I hope this is the right list for ext4-related user questions. If not, please point me in the right direction.

I recently set up my first software raid with mdadm and after adding more disks to the raid I am unable to resize the filesystem to the full size of the raid. I created a single (~16TB) filesystem on /dev/md0 via:

	mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0

This is wrong.  It should have been

mke2fs -v -b 4096 -t ext4 -T huge -E stride=128,stripe-width=256 /dev/md0

Unfortunately -t huge overrode the ".ext4" in "mkfs.ext4", leading to
an incorrect set of file system options.  I didn't expect people would
try to use do this.  I'll have to improve mke2fs's error handling to
prevent the -t/-T confusion.

That being said, you must have a non-standard /etc/mke2fs.conf file,
since when I tried your command line, here's the file system features
that I ended up with:

Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file

This wouldn't have given you any of ext4's advanced features, but
resize2fs should have worked in that case.

Can you send me the output of "dumpe2fs -h /dev/md0", and your
/etc/mke2fs.conf file?

While I await any suggestions, I'm going to look at a more
up-to-date versions of these tools. Please let me know if I need to
provide any more information. I *really* would like to find out that
there's a way to resize the fs without having to recreate the
fs. Copying all of this data off and back on would be painful.

Yes, you should definitely get a newer version of e2fsprogs.  The
latest version is 1.42.5.

As to whether you'll need to recreate the filesystem, I'll need to see
the output of dumpe2fs -h.  It may be that file system was created in
sufficiently poor configuration that it would be highly advisable that
you recreate the file system.

My apologies for the confusion with the options parsing.  Originally
the goal was to allow new fs-types (ext2/ext3/ext4) specified with -t,
and new usage-types (huge/big/small/etc.) specified with -T, to be
defined via new stanzas in /etc/mke2fs.conf.  The problem came when we
also added backwards compatibility support for argv[0] being set to
mkfs.<fs-type>.

That's not something I normally use --- I normally use mke2fs and
e2fsck directly --- and so it didn't occur to me that there would be
confusion if someone confused -t and -T while using an argv[0] of
mkfs.ext4.

Regards,

						- 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


Hi,

I,ve got the same problem. I tried it with e2fsprogs from Ubuntu 12.04 (1.4.2) and v1.42.5 from git repository. As mke2fs.conf i used the one from git, I guess there is no need to post it here ;)

cmd used to create fs:

mke2fs -t ext4 -T huge -O resize_inode \
-E stride=256,stripe-width=2048 /dev/sde1

the result is the same with both versions, here the dumpe2fs:

dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          901e6200-8e6a-4ea5-92c1-5f0f6502b302
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              366211072
Block count:              5859352064
Reserved block count:     292967603
Free blocks:              5836000801
Free inodes:              366211061
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              256
RAID stripe width:        2048
Flex block group size:    16
Filesystem created:       Mon Aug 27 13:18:02 2012
Last mount time:          n/a
Last write time:          Mon Aug 27 13:18:16 2012
Mount count:              0
Maximum mount count:      -1
Last checked:             Mon Aug 27 13:18:02 2012
Check interval:           0 (<none>)
Lifetime writes:          173 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      45b36dc8-4c59-453c-88d3-cb6b69747ffd
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00000001
Journal start:            0


and now the resize cmd:

resize2fs -p /dev/sde1 18000G

resize2fs 1.42.5 (29-Jul-2012)
resize2fs: /dev/sde1: The combination of flex_bg and
        !resize_inode features is not supported by resize2fs.

I've found this patch while googling, but i don't know if it is a solution for this problem. Heres the link:

http://www.spinics.net/lists/linux-ext4/msg20570.html


Thanks.

Kai Grosshaus







--
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


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux