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