resize2fs does not start to actually grow an ext4
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
e2fsprogs (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Confirmed
|
High
|
Unassigned |
Bug Description
Ubuntu 14.04 LTS, all proposed updates done
Kernel: 3.13.0-24-generic,
Package: e2fsprogs 1.42.9-3ubuntu1,
System: Haswell i7, 32GB RAM, LSI SAS 9207-8i HBA and LSI SAS 9211-8i HBA
I tried to increse the size of an ext4 filesystem. Old size 20TB, wanted new size 28TB. I tried offline resize with "resize2fs -fp /dev/md2" and later online resize using "resize2fs -f /dev/md2". In both cases, after giving the command a rezise2fs process is created that uses nearly 100% cpu according to top, but it does not perform any actual resize. It only prints its version and date and then it does not finish for hours. I had it running for more than a day without finishing:
root@marvin:~# resize2fs -f /dev/md2
resize2fs 1.42.9 (4-Feb-2014)
There is never more terminal output than that. It looks to me that resize2fs hangs in a endless calcualtion or loop or something similar.
Some more info about the filesystem:
root@marvin:~# tune2fs -l /dev/md2
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: data
Last mounted on: /media/data01
Filesystem UUID: e3845e15-
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 305225728
Block count: 4883606400
Reserved block count: 0
Free blocks: 22919919
Free inodes: 302894731
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 2048
Inode blocks per group: 128
RAID stride: 128
RAID stripe width: 640
Flex block group size: 16
Filesystem created: Fri Sep 20 19:45:01 2013
Last mount time: Tue May 20 02:14:37 2014
Last write time: Tue May 20 02:14:37 2014
Mount count: 3
Maximum mount count: -1
Last checked: Tue May 20 01:34:05 2014
Check interval: 0 (<none>)
Lifetime writes: 34 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: 569ec5fc-
Journal backup: inode blocks
I did also run an filesystem check:
root@marvin:~# e2fsck -vfp /dev/md2
2330890 inodes used (0.76%, out of 305225728)
14882 non-contiguous files (0.6%)
949 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
4868171016 blocks used (99.68%, out of 4883606400)
0 bad blocks
1654 large files
2273776 regular files
57105 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
2330881 files
The underlying device is an mdadm RAID6 that was grown from 7 to 9 disks. The growing finished without problems before I tried to increase the ext4 size.
Solution:
The solution for me was to downgrade to e2fsprogs 1.42.8. Then the resize did work and finished within a few minutes. I got the hint to do so in a forum from an user, who had the same problem and solved it with the older version. I have not tested the new 1.42.10.
I think this must be a bug introduced in the e2fsprogs version 1.42.9, because all works as expected with the older version.
I hope this helps to identify the problem. Best regards, Joerg
tags: | added: trusty |
Changed in e2fsprogs (Ubuntu Trusty): | |
milestone: | none → trusty-updates |
Changed in e2fsprogs (Ubuntu Trusty): | |
importance: | Undecided → High |
I had similar problem, 24TB raid 6 array growing to 48TB raid 6 array. Downgraded to 1.42.8 and was able to resize filesystem. However, with 20TB raid 5 grown to 24TB raid 5 I did not encounter issue.