touch-packages team mailing list archive

[TJ <ubuntu@xxxxxx>]

Increasing importance due to possible denial-of-service during a resize
of large 'complex' file-systems. In this case both reports using DM RAID
6.

** Changed in: e2fsprogs (Ubuntu)
   Importance: Undecided => High

** Changed in: e2fsprogs (Ubuntu)
       Status: Confirmed => Triaged

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

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