Comment 6 for bug 1756315

Revision history for this message
Lukas Dzunko (lukas-d) wrote :

I can confirm this bug on Ubuntu 16.04.6 LTS. Apparently it is related to latest kernel update (in my case HWE).

-------------------------------------------------------------------------------
Affected version:

Linux version 4.15.0-58-generic (buildd@lgw01-amd64-037) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)) #64~16.04.1-Ubuntu SMP Wed Aug 7 14:10:35 UTC 2019

root@lukas:~# time fstrim -v /
/: 206.6 GiB (221849395200 bytes) trimmed

real 22m18.448s
user 0m0.001s
sys 0m18.827s
root@lukas:~#

lukas@lukas:~$ collectl -s d -i 1
waiting for 1 second sample...
#<----------Disks----------->
#KBRead Reads KBWrit Writes
      0 0 0 0
      8 1 0 0
      8 1 4344 1083
      0 0 21848 1939
      0 0 26420 1360
      0 0 24468 1275

... Normally I see spike in write and fstrim is done within seconds. On version 4.15.0-58-generic is taking 20 to 30 minutes to complete. During this time I see write to disk at around 25 - 30 MB/s and overall system experience is slow (UI response, load time, speed of file operations)

-------------------------------------------------------------------------------
Unaffected version:

Linux version 4.15.0-55-generic (buildd@lgw01-amd64-038) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)) #60~16.04.2-Ubuntu SMP Thu Jul 4 09:03:09 UTC 2019

root@lukas:~# time fstrim -v /
/: 144.4 GiB (155019710464 bytes) trimmed

real 0m3.185s
user 0m0.006s
sys 0m0.000s
root@lukas:~#

lukas@lukas:~$ collectl -s d -i 1
waiting for 1 second sample...
#<----------Disks----------->
#KBRead Reads KBWrit Writes
      0 0 0 0
      0 0 86398K 71
      0 0 61439K 45
      0 0 0 0
      0 0 0 0

... I rebooted my laptop to previous kernel version. e.g. Same userspace, only kernel change. Fstrim finished within few seconds. Collectl + system load indicator displayed much higher write throughput during fstrim operation.

-------------------------------------------------------------------------------

I see same behaviour on both my laptops. Both are configured in way SSD -> partitions -> luks -> btrfs. Primary laptop have disk "SanDisk SD7SN6S-512G-1006". Backup laptop "Micron C400 RealSSD 256GB mSATA". I don't see this problem on disks attached via iSCSI.

-------------------------------------------------------------------------------

... while writing this post I noticed that there is different amount of "trimed" data reported. This may be due to snapshots being released (I was capturing data +- at time when daily snapshots are released) and not some kind of destructive problem ...