© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Performing verification for Focal.
I'm going to do three rounds of verification.
The first is the testcase from this bug, showing block discard performance.
The second is running through the regression reproducer from bug 1907262.
The third will be results from my testing with my /home directory on a cloud instance with Raid10 backed disks, 3x customer testing and 2x community user testing. This will be in a separate comment closer to the release date once I have collected results.
Starting with the testcase for this bug.
I started a i3.8xlarge instance on AWS, enabled -proposed and installed 5.4.0-75-generic. From there, I ran through the testcase of making a Raid10 array, and formatting it with xfs, and block discard performance was excellent:
https:/
It took 6.6 seconds to format the array with xfs, and 3.8 seconds for a fstrim, as opposed to the 20 minutes it took beforehand.
Performance with block discard is excellent.
Moving onto the second testcase, the regression reproducer from bug 1907262.
I started a n1-standard-2 VM on Google Cloud, and attached 2x NVMe scratch disks. I enabled -proposed and installed 5.4.0-75-generic. I ran through the testcase of making a Raid10 array, doing consistency checks, ensuring that mismatch count is 0, creating a file, deleting it, performing a fstrim, and more consistency checks, then taking the raid array down and bringing up one disk at a time, and performing a fsck.ext4. All disks came back clean:
https:/
Since the block discard performance is there, and there is no apparent data corruption going on after a fstrim, I will mark this verified for Focal.