Fstrim and iostat

iossdtrim

I have a new samsung ssd in my new notebook. I tuned up everything to avoid writings in the disk (firefox profiles and /var/log in memory), I'm using a ext4 fs with relatime and I use fstrim once a day to TRIM my ssd.

I monitor disk load with iostat -dhm. Before running fstrim the command iostat shown

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda
              4.97         0.05         0.59       1856      20924

after trimming /home

# fstrim -v /home
/home: 100.2 GiB (107555401728 bytes) trimmed

ìostat shows

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda
              5.91         0.05         3.51       1859     123498

MB_wrtn increased 102574 MB.
Does that mean fstrim is writing 102574 MB = 100.2 GB to my disk ?

Trim is supposed to "mark" the pages that do not contain valid data, not writing them.

I guess iostat saw the operation made by fstrim as writing (even if it is not a writing). What do you think? Is there a better way to monitor my disk?

Note: Using iotop is not an answer, because it doesn't show the amount of data of processes that were killed. Thus, iotop measurement
is inexact.

Best Answer

MB_wrtn increased 102574 MB. Does that mean fstrim is writing 102574 MB = 100.2 GB to my disk ?

Yes, it means exactly that. fstrim essentially looks at every single block of your block device and decides if the block is being used by the filesystem (that is, contains important data):

block is in use: ignore it.
block is not in use: send an ATA TRIM command for this block to the underlying block device.

When it's done, the amount of trimmed blocks should always be equivalent to the free space on the filesystem. fstrim TRIMs each free block every time you run it, regardless if it already has been TRIMmed in the past, so it won't become faster if you run it more often.

The kernel probably considers the TRIM command like a write command, so every executed TRIM command counts as a 4k write command.

Trim is supposed to "mark" the pages that do not contain valid data, not writing them.

"Marking" blocks as trimmed is equivalent to "writing" them, because their contents change. If you'd accidentally TRIM the wrong block, you would lose data - just as writing zeros to the wrong block causes you to lose data.

Related Solutions

How to run SSD trim fstrim on btrfs when mounted multiple subvolumes

fstrim should run on "mountpoint", so you need to have devices mounted. But you only need to call it once per physical device. So if 2 mountpoints are on the same device with btrfs, you only need to call fstrim on one mountpoint.

Finding this answer: https://forums.gentoo.org/viewtopic-t-1003980-view-previous.html?sid=a51dab49787e5b7b6c2fa4aa7c1a5e44

I do it like this :

#!/bin/sh
LOG=/var/log/fstrim.log
echo "===" $(date -R) "===" >> $LOG
for d in $(lsblk -o MOUNTPOINT,FSTYPE | grep -E 'btrfs' | awk '{print $1}'); do
    fstrim -v $d 2>&1 >> $LOG
done

This script is placed in /etc/cron.weekly/fstrim and set executable:

sudo chmod +x /etc/cron.weekly/fstrim

The script makes use of lsblk that list block devices. I'm searching "btrfs" devices and I launch fstrim on it.

SSD Maintenance – How Often to Run fstrim?

TRIM does at least three things:

minimize write amplification
prevent long-term performance degradation
irrecoverably delete your data

Now it depends where your priorities are.

For 1), you should not be using fstrim at all, but make use of the discard option of your filesystem. Only if everything is trimmed instantly will the SSD stop copying no longer needed bits of data around. In practice though, it has been shown that preventing write amplification is not that important since SSD are fine with lots of writes.

For 2), using fstrim weekly or even monthly is completely fine. There is no need to use instant discard, or to trim daily - that would be a short-term measure, but this is about keeping the SSD happy in the long-term. But it also depends on your usage: if your filesystem is always full and sees lots of writes, you might need to trim more regularly than if you tend to have lots of free space and not that much writes in your filesystems.

For 3), you should not be using any kind of trim at all. Basically if you expect to be human, making errors, having accidents - like you just deleted your photo collection, whoops - recovery tools like photorec won't work after TRIM because with TRIM everything is gone forever.

From a pure data recovery point of view, SSD is a huge headache. There's too much trim happening in Linux, even without asking you (mkfs implies trim, lvremove/lvresize/... might if issue_discards, some partitioners might be having ideas, ...). Suddenly previously reversible actions become irreversible, all for the sake of getting a few more points in some filesystem benchmark...

If you decide on fstrim you should know where the cron job is located so you can disable it when you have an accident, that way you get a compromise between 2) and 3). In general with SSD you should make sure you have good backups, they are even more important than with HDD since you have lesser chance of recovery on SSD.

Best Answer

Related Solutions

How to run SSD trim fstrim on btrfs when mounted multiple subvolumes

SSD Maintenance – How Often to Run fstrim?

Related Question