resize2fs hoses a filesystem on lvm after resizing

[Maurice Volaski]

Resized an ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, three errors were found.

root@ubuntu:~# e2fsck -f /dev/ubuntu-vg/root
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 21110 extent block passes checks, but checksum does not match extent
 (logical block 18432, physical block 503808, len 3813)
Fix<y>? no
Inode 26807 extent block passes checks, but checksum does not match extent
 (logical block 34816, physical block 768000, len 896)
Fix<y>? no
Inode 28306 extent block passes checks, but checksum does not match extent
 (logical block 30720, physical block 430080, len 5130)
Fix<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

This setup is currently in a virtual machine with a snapshot, so I can revert back and retest. The resize2fs is coming from the 18.04 Ubuntu CD.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: e2fsprogs 1.44.1-1
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CasperVersion: 1.394
CurrentDesktop: ubuntu:GNOME
Date: Thu Jun 21 21:03:56 2018
LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: e2fsprogs
UpgradeStatus: No upgrade log present (probably fresh install)

[Maurice Volaski (maurice-volaski)]

The bug is also present resize2fs 1.43.6. I tried to post directly to sourceforge for the project, but it doesn't allow me.

[Theodore Ts'o (tytso)]

#1 Was this an on-line or off-line resize? That is, was the file system mounted at the time when you ran resize2fs?

#2 Can you post a copy of dumpe2fs before you started to resize?

#3 How big were you trying to resize the file system to become?

It's great that you have a snapshot of the file system pre-resize, since that means we can test potential fixes. If you can keep a snapshot of that exist file system image while I investigate this failure, it would be much appreciated.

[Maurice Volaski (maurice-volaski)]

This was offline, run off the Ubuntu live cd. I will get back to you on the rest on Monday.

From: <email address hidden> on behalf of Theodore Ts'o <email address hidden>
Reply-To: Bug 1778140 <email address hidden>
Date: Friday, June 22, 2018 at 19:50
To: Maurice R Volaski <email address hidden>
Subject: [Bug 1778140] Re: resize2fs hoses a filesystem on lvm after resizing

#1 Was this an on-line or off-line resize? That is, was the file
system mounted at the time when you ran resize2fs?

#2 Can you post a copy of dumpe2fs before you started to resize?

#3 How big were you trying to resize the file system to become?

It's great that you have a snapshot of the file system pre-resize, since
that means we can test potential fixes. If you can keep a snapshot of
that exist file system image while I investigate this failure, it would
be much appreciated.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1778140

Title:
  resize2fs hoses a filesystem on lvm after resizing

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  Resized an ext4 filesystem on LVM. Before resizing, I confirmed
  filesystem was clean with e2fsck. After resizing, three errors were
  found.

  root@ubuntu:~# e2fsck -f /dev/ubuntu-vg/root
  e2fsck 1.44.1 (24-Mar-2018)
  Pass 1: Checking inodes, blocks, and sizes
  Inode 21110 extent block passes checks, but checksum does not match extent
                (logical block 18432, physical block 503808, len 3813)
  Fix<y>? no
  Inode 26807 extent block passes checks, but checksum does not match extent
                (logical block 34816, physical block 768000, len 896)
  Fix<y>? no
  Inode 28306 extent block passes checks, but checksum does not match extent
                (logical block 30720, physical block 430080, len 5130)
  Fix<y>? no
  Pass 2: Checking directory structure
  Pass 3: Checking directory connectivity
  Pass 4: Checking reference counts
  Pass 5: Checking group summary information

  This setup is currently in a virtual machine with a snapshot, so I can revert back and retest. The resize2fs is coming from the 18.04 Ubuntu CD.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: e2fsprogs 1.44.1-1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CasperVersion: 1.394
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 21 21:03:56 2018
  LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: e2fsprogs
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1778140/+subscriptions

[Maurice Volaski (maurice-volaski)]

Here is the dump2efs before the filesystem resize was attempted.

[Maurice Volaski (maurice-volaski)]

Here is the output after the resize. The original was 59.02 GB and I am resizing to 30G.

[Theodore Ts'o (tytso)]

OK so it looks like you were trying to shrink a file system from 59G to 30G (using an off-line resize, since on-line resizing only supports growing a file system).

Hmm.... are you willing to send me (probably off-line) a metadata-only dump of the "before" file system? See the e2image page, and read the section "QCOW2 IMAGE FILES". I can use the metadata-only file system to reproduce the problem on my end, by running resize2fs on the raw metadat-only file system.

[Maurice Volaski (maurice-volaski)]

image of files system in the before state

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.