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
I then waited painfully for a couple of days as all of the data from the old raid copied over to the new raid; I moved over the disks and grew the raid and then finally I:
resize2fs -p /dev/md0
Which informs me that
resize2fs 1.42 (29-Nov-2011)
resize2fs: /dev/md0: The combination of flex_bg and !resize_inode features is not supported by resize2fs
I lack any understanding of exactly what these two features are for or why the combination is troublesome, so against my better judgement I tried to add resize_inode:
tune2fs -O +resize_inode /dev/md0
But I got shot down:
Setting filesystem feature 'resize_inode' not supported.
And I'm not brave enough to try to remove flex_bg as I really don't want to do anything that might put my data at risk. I'm running Ubuntu 12.04 with the 3.5.1 kernel:
Linux critter 3.5.1-030501-generic #201208091310 SMP Thu Aug 9 17:11:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
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.
Any help would be appreciated.
Thanks.
--
Curtis Jones
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
On Aug 20, 2012, at 23.02.45, Theodore Ts'o <[email protected]> wrote:
> Yes, you should definitely get a newer version of e2fsprogs. The
> latest version is 1.42.5.
Done.
> 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.
Thanks for the reply. Below, as requested, the output from dumpe2fs and the mke2fs.conf file (Ubuntu 12.04). I look forward to hearing that my file system isn't in a state of "sufficiently poor configuration"; however, since I originally posted my question I've managed to secure a means to duplicate the data so that I can recreate the file system (if necessary).
Thanks a lot for your help.
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: /media/Bigger
Filesystem UUID: baecfa03-74c1-42ad-8e19-3b823f05f502
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype extent 64bit flex_bg sparse_super large_file 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: 274700288
Block count: 4395202560
Reserved block count: 219760128
Free blocks: 247712956
Free inodes: 274636266
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: 128
RAID stripe width: 768
Flex block group size: 16
Filesystem created: Fri Aug 17 02:54:50 2012
Last mount time: Mon Aug 20 02:21:51 2012
Last write time: Mon Aug 20 12:28:57 2012
Mount count: 0
Maximum mount count: -1
Last checked: Mon Aug 20 12:28:57 2012
Check interval: 0 (<none>)
Lifetime writes: 16 TB
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: b357ba49-60b1-4c55-837f-a70c8285a8f5
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00009b36
Journal start: 0
[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 0
blocksize = 4096
inode_size = 256
inode_ratio = 16384
[fs_types]
ext3 = {
features = has_journal
}
ext4 = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
auto_64-bit_support = 1
inode_size = 256
}
ext4dev = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
options = test_fs=1
}
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
floppy = {
blocksize = 1024
inode_size = 128
inode_ratio = 8192
}
big = {
inode_ratio = 32768
}
huge = {
inode_ratio = 65536
}
news = {
inode_ratio = 4096
}
largefile = {
inode_ratio = 1048576
blocksize = -1
}
largefile4 = {
inode_ratio = 4194304
blocksize = -1
}
hurd = {
blocksize = 4096
inode_size = 128
}
--
Curtis Jones
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 [email protected]
> 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
On 8/27/2012 6:37 AM, Kai Grosshaus wrote:
> 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 [email protected]
>> 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:
> ...
Hello,
I'm in the same boat I'm afraid, but I do have a question. I'm curious
whether the issue with the combination of flex_bg and !resize_inode can
cause problems *shrinking* the filesystem, or if it is only a risk when
growing it(?). I need to shrink the fs to get enough space for LVM
snapshots. I figure that if shrinking is not an issue I could just
compile a version of e2fsprogs without the check for this feature
combination, just to use this once. I mean, I already have to reformat
so I'm no worse off if it doesn't work. Any thoughts on the likelihood
of that working?
Here are some details:
My filesystem (~16T) was also created under Ubuntu 12.04 using the
included e2fsprogs 1.42 with no changes to mke2fs.conf. It is now being
used under Ubuntu 8.04 but I've installed e2fsprogs v1.42.5.
I don't have the exact mkfs command that I used to create it on hand,
but if it matters I know I called it as mkfs.ext4, I set stride and
stripe-width appropriately, used a 1G journal, and used something around
'-m .25'
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: /media/dlr6
Filesystem UUID: 3652885c-e8c6-4f4d-86a0-a4c1d1784557
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype
needs_recovery extent 64bit flex_bg sparse_super large_file 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: 272199680
Block count: 4355184640
Reserved block count: 10887961
Free blocks: 2325348918
Free inodes: 263549083
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: 64
RAID stripe width: 576
Flex block group size: 16
Filesystem created: Sun Sep 9 18:40:39 2012
Last mount time: Tue Oct 30 20:03:15 2012
Last write time: Tue Oct 30 20:03:15 2012
Mount count: 16
Maximum mount count: -1
Last checked: Sun Sep 9 18:40:39 2012
Check interval: 0 (<none>)
Lifetime writes: 10 TB
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
First orphan inode: 213188625
Default directory hash: half_md4
Directory Hash Seed: 94884f6d-8b2e-4830-a33b-02652aee727c
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x024d20c1
Journal start: 1
Thanks in advance for any insight,
Mark