Comment 4 for bug 1896154

Performing verification for Focal.

I created a i3.large instance on AWS, since it has 1x NVMe drive that supports trim and block discard.

I ensured that I could reproduce the problem with 5.4.0-54-generic from -updates, and I followed the instructions in the Testcase section, and the final fstrim after shrinking locked up the instance, and filled up the root disk. I terminated the instance.

I then created a new instance, and enabled -proposed, and installed 5.4.0-55-generic, and rebooted. From there, I ran though the test steps again:

$ uname -rv
5.4.0-55-generic #61-Ubuntu SMP Mon Nov 9 20:49:56 UTC 2020
$ sudo -s
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 28.1M 1 loop /snap/amazon-ssm-agent/2012
loop1 7:1 0 97.8M 1 loop /snap/core/10185
loop2 7:2 0 55.3M 1 loop /snap/core18/1885
loop3 7:3 0 70.6M 1 loop /snap/lxd/16922
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
nvme0n1 259:0 0 442.4G 0 disk
# dev=/dev/nvme0n1
# mnt=/mnt
# mkfs.btrfs -f $dev -b 10G
btrfs-progs v5.4.1
See http://btrfs.wiki.kernel.org for more information.

Detected a SSD, turning off metadata duplication. Mkfs with -m dup if you want to force metadata duplication.
Label: (null)
UUID: db9dd9f5-7993-4827-9a43-93a72a73aa3a
Node size: 16384
Sector size: 4096
Filesystem size: 10.00GiB
Block group profiles:
  Data: single 8.00MiB
  Metadata: single 8.00MiB
  System: single 4.00MiB
SSD detected: yes
Incompat features: extref, skinny-metadata
Checksum: crc32c
Number of devices: 1
Devices:
   ID SIZE PATH
    1 10.00GiB /dev/nvme0n1

# mount $dev $mnt
# fstrim $mnt
# btrfs filesystem resize 1:-1G $mnt
Resize '/mnt' of '1:-1G'
# fstrim $mnt
#

The final fstrim completed almost immediately, the same speed as the initial fstrim. The instance did not lock up, and the root disk did not get filled with any garbage data.

The kernel in -proposed fixes the problem, happy to mark as verified.