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
... 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)
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
... 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 ...
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 -----Disks- ------- --->
waiting for 1 second sample...
#<-----
#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 -----Disks- ------- --->
waiting for 1 second sample...
#<-----
#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 ...