Why fstrim Doesn’t Trim Data Blocks on btrfs with ecryptfs

btrfsecryptfsfilesystemsfstrimtrim

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.

Best Answer

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.

lsof

The only way I can think to gain access to a mount such as this would be to mount it as you did before using Nautilus or whatever file browser, and then using a tool such as lsof to see what files/devices are opened by Nautilus.

$ lsof -p $(pgrep nautilus)

But if you're having to connect to your phone via gphoto2 then you're likely not mounting the device a a mass storage device but rather a PTP - Picture Transfer Protocol. There's a Linux FUSE implementation for PTP too.

gvfs?

I would also look in your $HOME directory for a sub-directory called .gvfs. Usually when GNOME or Nautilus are doing the mounting this directory is created as a convenience.

In newer versions of GNOME (3+) this directory has moved and is now here, /run/user/$UID/gvfs.

Example

$ ls -l /run/user/$UID/gvfs/smb-share\:server\=tank\,share\=t 
total 2
drwx------. 1 saml saml    0 Oct 31 09:16 Development
drwx------. 1 saml saml    0 Nov 18 14:52 home
drwx------. 1 saml saml    0 May 14  2013 incoming
...

NOTE: That's a environment variable $UID that is often set in Bash on most modern systems. If it isn't set you can find your user's ID like so:

$ id
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Ubuntu – ext4 filesystems frequently corrupting

All three data journaling modes should leave the filesystem itself fully intact after a power failure. So it should always mount without errors. The difference is only in the data in your files; data=writeback mode may leave stale data (i.e., what was stored in the disk sectors before the writes your app did). data=ordered and data=journaled should not do this.

Most likely what you're seeing is that I/O barriers aren't working on your setup. First, make sure you're not mounting with barrier=0/nobarrier. That boosts performance, but will cause corruption on power failure.

If I/O barriers are on, it's also possible you're passing through a storage layer that doesn't support them. On older releases, LVM didn't and various mdraid levels didn't. (This was fixed in Linux 2.6.33; so only if you're running Lucid still.)

Finally, it's possible your disks are telling lies. Disks have write caches. Especially with NCQ, they're supposed to only tell the OS they've written data when they've actually done so, but they've been known to tell the OS its written when its only in the disk's write cache. Increases performance. At least as long as the power stays on. You can try disabling the write cache on the disks, though you'll take a performance hit for this.

Note also that flash-memory disks have a lot of work to do under the hood, and many of them don't handle power failure well. (For example, wear leveling sometimes requires that a full flash block of data be moved. If the power fails in the middle, bad things happen on some flash disks.)

Finally... have you considered an UPS?

Best Answer

Related Solutions

How to mount a filesystem from a given USB bus:device

lsof

gvfs?

Example

Ubuntu – ext4 filesystems frequently corrupting

Related Question