Повреждение файловой системы ext4 после добавления tune2fs для установки UUID?

Мы только что выпустили новую версию наших систем Ubuntu 16.04 в AWS. Помимо обновления apt-get и всего, мы добавили явный шаг в наш код кукол, чтобы использовать tune2fs для добавления UUID на диски ext4. (Это готовится к переходу на типы экземпляров Amazon c5, которые используют имена устройств nvme, и мы хотим знать, какой диск какой до и после.)

Но затем нам нужно было перезагрузить большое количество этих систем, чтобы изменить их размер в AWS (то же семейство экземпляров), и около 10% из них потерпели неудачу из-за повреждения файловой системы на своих дисках данных (не на корневом диске).

grep -i ext4 /var/log/kern.log |grep xvdh
2019-03-14T14:07:39.954930+00:00 ip-10-2-219-30 kernel: [   26.059585] 
EXT4-fs (xvdh): ext4_check_descriptors: Checksum for group 0 failed                 (25645!=13919)
2019-03-14T14:07:39.961718+00:00 ip-10-2-219-30 kernel: [   26.064303]         EXT4-fs (xvdh): group descriptors corrupted!
2019-03-14T14:07:54.984741+00:00 ip-10-2-219-30 kernel: [   41.090302] EXT4-fs (xvdh): ext4_check_descriptors: Checksum for group 0 failed (25645!=13919)
2019-03-14T14:07:54.984757+00:00 ip-10-2-219-30 kernel: [   41.094897] EXT4-fs (xvdh): group descriptors corrupted!
2019-03-14T14:08:17.138117+00:00 ip-10-2-219-30 kernel: [   63.239655] EXT4-fs (xvdh): ext4_check_descriptors: Checksum for group 0 failed (25645!=13919)
2019-03-14T14:08:17.138141+00:00 ip-10-2-219-30 kernel: [   63.246723] EXT4-fs (xvdh): group descriptors corrupted!
2019-03-14T14:21:30.636962+00:00 redacted1 kernel: [    3.798075] EXT4-fs (xvdh): mounted filesystem with ordered data mode. Opts: (null)
2019-03-14T14:46:07.812220+00:00 redacted2 kernel: [    3.614731] EXT4-fs (xvdh): mounted filesystem with ordered data mode. Opts: (null)

Затем мы должны fsck диск, чтобы восстановить систему.

Код марионетки, который делает это изменение, следует. Пока что мы используем только типы экземпляров M4/C4, поэтому все они должны быть /dev/xvdh.

class our_storage::platforms::aws {

  # This shouldn't run during image generation.
  if $::packer_build != 'yes' {

    # If nvme0n1 is present this means we are using a M5 or C5 instance and then the data volume will be nvme1n1
    # We need to check the disk that are mounted in / because it might take time for the data volume to appear as totally mounted to the instance.
    # xvda    --> xvdh
    # nvme0n1 --> nvme1n1
    if $facts['disks']['nvme0n1'] {
      $st_volume = '/dev/nvme1n1'
    }
    elsif $facts['disks']['xvda'] {
      $st_volume = '/dev/xvdh'
    }
    else {
      fail("Invalid disk configuration ${facts['disks']}")
    }

    $fstype = 'ext4'
    $mount_opts = 'auto,noatime'

    # If /data is not mounted, go ahead and do it.
    if !$facts['mountpoints']['/data'] {

      # Get an unique, constant UUID for this volume.
      $ec2_userdata = parsejson($facts['ec2_userdata'])
      $domain = $ec2_userdata['domain']
      $subdomain = $ec2_userdata['subDomain']
      $st_volume_uuid = fqdn_uuid("${subdomain}.${domain}")

      # we may have to wait for the device to "appear"
      exec { 'Storage: waiting for data volume to be attached':
        path      => '/bin',
        command   => "lsblk -fn ${st_volume}",
        tries     => 60,
        try_sleep => 10,
        unless    => 'mountpoint -q -- "/data"',
        logoutput => true,
      } -> exec { 'Storage: formatting data volume': # WARNING: if we ever change from ext4, this will reformat volumes!
        path      => ['/sbin', '/bin'],
        command   => "mkfs.${fstype} -F ${st_volume}",
        unless    => "blkid ${st_volume} | grep -q 'TYPE=\"${fstype}\"'",
        logoutput => true,
      } -> exec { 'Storage: assign UUID to data volume':
        path      => ['/sbin', '/bin'],
        command   => "tune2fs ${st_volume} -U ${st_volume_uuid}",
        logoutput => true,
      } ~> mount { '/data':
        ensure  => mounted,
        device  => "UUID=${st_volume_uuid}",
        fstype  => $fstype,
        options => $mount_opts,
        require => File['/data'],
        before  => File[$our_storage::data_dirs],
      }
    } else {
      # Need to fetch the current UUID.
      # Cannot be changed if the volume is already mounted!
      $st_volume_uuid = $st_volume ? {
        '/dev/nvme1n1' => get_disk_uuid('/dev/nvme1n1'),
        '/dev/xvdh'    => get_disk_uuid('/dev/xvdh')
      }

      # If data is already mounted, just make sure that everything in fstab is in place.
      # e.g. it is using the UUID as disk identifier.
      mount { '/data':
        ensure  => mounted,
        device  => "UUID=${st_volume_uuid}",
        fstype  => $fstype,
        options => $mount_opts,
        require => File['/data'],
        before  => File[$our_storage::data_dirs],
      }
    }
  }
}

Мы не смогли выяснить, является ли это изменение виновником - кажется, это единственное существенное существенное изменение, но мы не можем понять, как это могло бы испортить вещи... Одна вещь, которую мы можем соотнести, заключается в том, что это кажется несколько Смещение в сторону загруженных систем, в которых устанавливаемый нами диск EBS разумно нарушает баланс, поэтому может быть медленным.

Мы пытались воспроизвести это на флоте систем разработки, но не смогли спровоцировать тот же сбой.

Я знаю, что мы могли бы автоматизировать fsck, но это в некотором роде касается того, что наносит ущерб в первую очередь; что произойдет, если он сломает вещи больше, чем fsck может исправить без присмотра? У нас большой флот.

Существуют ли какие-либо известные способы, которыми выполнение tune2fs в медленной или все еще монтируемой системе может повредить файловую систему ext4, или есть что-то еще очевидное, что мы делаем, что приведет к такому повреждению? И что мы можем сделать, чтобы определить, так ли это? Поскольку это периодически не воспроизводится, и произошли другие изменения (обновления пакетов и все), мы не можем быть уверены, что причиной является добавление UUID, но оно точно подозрительно по времени.