[Touch-packages] [Bug 1321958] Re: resize2fs does not start to actually grow an ext4
** Attachment added: resize.1.42.8.debug.gz https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321958/+attachment/4159872/+files/resize.1.42.8.debug.gz -- 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: 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
[Touch-packages] [Bug 1321958] Re: resize2fs does not start to actually grow an ext4
This bug also affects me. I have tested the new 1.42.11 but no success. Attached the strace; the debug log is empty for my setup also. In addition I added a strace/debug file of the 1.42.8 which worked. I hope that might be helpful. ** Attachment added: resize.1.42.11.strace https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321958/+attachment/4159870/+files/resize.1.42.11.strace -- 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: 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
