Doesn't look like the fixed version was ever pushed out to Trusty. If you are using trusty and need this fixed, simply download the source to your machine and compile it. If you have the build-essential and git packages installed, it's quite simple. Clone the git repo source for the latest version and then cd into it and type: ./configure make
After that, you will have the needed binaries in that folder. You can run them directly from there when you want to use that version rather than the on in Trusty. I compiled 1.43.6 from source and used resize2fs from there to successfully resize from 21 -> 24 TB on a RAID6. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1321958 Title: resize2fs does not start to actually grow an ext4 Status in e2fsprogs package in Ubuntu: Fix Released Status in e2fsprogs source package in Trusty: Confirmed 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-0336-47ae-8aec-df75acb217c5 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_directory_hash 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-4d5e-4639-bef3-42cde5fbe948 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 Extent depth histogram: 2317190/13041/651 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
