5

I have an SSD disk with several partitions. One of them is has a btrfs volume, mounted as /home, which holds an ecryptfs home directory.

When I trim the volumes, it seems that fstrim doesn't trim data blocks on such volume - why? Below you can see all the informations about the setup, and the procedure I follow, with comments.

$ cat /etc/fstab:

UUID=xxx /               ext4    errors=remount-ro 0       1
UUID=yyy /media/vfio     ext4    defaults          0       2
UUID=zzz /home           btrfs   defaults          0       2

$ mount | grep sda:

/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sda1 on /media/vfio type ext4 (rw,relatime,stripe=32721,data=ordered)
/dev/sda2 on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

$ ls -la /home /home/myuser/.Private # summary:

/home:
.ecryptfs
myuser

/home/myuser/.Private -> /home/.ecryptfs/myuser/.Private

$ df -h:

Filesystem              Size  Used Avail Use% Mounted on
/dev/sda5                16G   11G  4,7G  69% /
/dev/sda1                93G   52G   36G  60% /media/vfio
/dev/sda2               828G  542G  286G  66% /home
/home/myuser/.Private   828G  542G  286G  66% /home/myuser

I execute fstrim on all the volumes, for the first time.

$ fstrim -va:

/home/myuser: 286,4 GiB (307518836736 bytes) trimmed
/home: 286,4 GiB (307485450240 bytes) trimmed
/media/vfio: 40,4 GiB (43318886400 bytes) trimmed
/: 5,4 GiB (5822803968 bytes) trimmed

It seems that fstrim runs twice on the /home tree, due to the additional ecryptfs mount. This would be ok (I could avoid it by running an fstrim with specific mountpoints). The problem is that trimming /home is not working as expected, as each run finds and trims the same amount of data.

This is shown by a further run.

$ fstrim -v / (this is ok):

/: 0 B (0 bytes) trimmed

$ fstrim -v /home (this isn't ok):

/home: 286,4 GiB (307478061056 bytes) trimmed

Note that the sda2 (/home) trimming takes some time to run, so it's actually doing something.

Marcus
  • 961

1 Answers1

7

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 <roughly free space> 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.

frostschutz
  • 48,978