On Wed, Feb 12, 2020 at 11:21 PM Roman Mamedov <rm@xxxxxxxxxxx> wrote: > > On Wed, 12 Feb 2020 23:08:03 -0700 > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > Host: kernel 5.5.3, qemu-kvm, Btrfs, backing file is raw with +C 5.6. > > Guest: kernel 5.6.0-rc1, / is Btrfs > > > > Boot and login, and immediately run these commands: > > > > [root@localhost ~]# df -h > > /dev/vda4 96G 4.4G 91G 5% / > > # fstrim -v / > > /: 91 GiB (97633062912 bytes) trimmed > > > > 1 minute later > > > > [root@localhost ~]# fstrim -v / > > /: 3.5 GiB (3747549184 bytes) trimmed > > [root@localhost ~]# Huh... these are about 10s apart. # uname -r 5.4.18-200.fc31.x86_64 [root@localhost ~]# fstrim -v / /: 92 GiB (98746789888 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3808149504 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.7 GiB (3993657344 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3812700160 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3812700160 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3812700160 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3812700160 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3812700160 bytes) trimmed [root@localhost ~]# fstrim -v / /: 3.6 GiB (3813261312 bytes) trimmed [root@localhost ~]# 3-4 minute gap # fstrim -v / /: 3.5 GiB (3729862656 bytes) trimmed OK and on baremetal with 5.5.3.. also 10s delay # fstrim -v / /: 82.6 GiB (88663547904 bytes) trimmed [root@fmac ~]# fstrim -v / /: 11.3 GiB (12157599744 bytes) trimmed [root@fmac ~]# fstrim -v / /: 11.3 GiB (12156633088 bytes) trimmed [root@fmac ~]# There's no good use case for multiple fstrim instance this short apart. I stumbled on it by accident while seeing what the behavior is of a fallocated file created inside a VM on a sparse raw file used as the VM's backing "device" - so at first I thought it was related to that but now it's obviously not related to VM stuff at all. I have fstrim.timer set to run fstrim.service once per week, and that reports sane (expected) values each time. But, it also tends to happen soon after a fresh boot or wake from S3. -- Chris Murphy
