TLDR: fstrim está reportando um número incorreto de bytes aparados.
Um muito pergunta semelhante foi perguntada no Unix Stackexchange. A resposta aceita afirma:
It is a common misunderstanding to worry about the sizes reported by fstrim.
It really doesn't mean anything. Just ignore it.
fstrim just issues the appropriate ioctl, everything else is the decision of the filesystem, and filesystems behave very differently. For example, ext4 tries to avoid trimming the same things over and over, so you will see 0 bytes trimmed. xfs doesn't care and trims everything that's free, so you'll always see bytes trimmed. Other filesystems may do other things, it all depends on how the filesystem chose to implement the FITRIM syscall logic, if it's implemented at all.
As long as the amount of data trimmed is not larger than free space, you should be fine regardless of what fstrim (the filesystem, really) reports.
In the end only the SSD itself really knows what's currently trimmed and what not. Trimming already trimmed blocks does not cause any harm whatsoever.
Don't make conclusions based on x bytes trimmed as reported by fstrim.
If you want to verify that data was trimmed, you have to check raw data on the disk. ( https://unix.stackexchange.com/a/85880/30851 ) but that method might not work for btrfs, I have never tried.
Eu perguntei ao OP sobre o caso exato que você descreveu (um sistema de arquivos ext4 relatando algumas centenas de MB aparadas mesmo que nenhuma atividade de gravação significativa ou exclusões tenham ocorrido. Ele respondeu com:
Once you make a small change, it will trim a large area (but still smaller than free space). Also it might not remember across reboots. I haven't looked at the implementation in detail, I guess it's just not that fine grained.