Ubuntu – Does TRIM work with FAT32

ssdtrim

I used this webupd8 guide to help me Trim my SSD on Ubuntu 13.10. The guide says that "you must make sure the partition(s) are EXT4 or BTRFS". Unfortunately, I stupidly assumed the HD was formatted to ext4; it's actually fat32.

The var/log/trim suggests that it's working:

*** Sun, 15 Dec 2013 11:30:42 +0000 ***
/: 50567962624 bytes were trimmed

But is it actually doing something? Or will I have to re-format the drive and start all over again?

Sorry if this sounds a little paranoid. Any reassurance much appreciated.

Best Answer

I see that this is an old question ... but it comes up early in searches on the topic, so it seemed to be worth giving an answer from the kernel sources.

There are two different ways a Linux filesystem implementation can "support" TRIM:

  • It can support the -o discard mount option, so blocks that become free are trimmed immediately

  • It can support the FITRIM ioctl, which is what the userland fstrim command uses to trim all currently-free blocks in bulk when requested

A given filesystem implementation can support one, or the other, or both (or none).

As it turns out, the FAT implementation has been able to do discard since kernel 2.6.28. That even predates the mount option, which didn't appear until 2.6.33. From 2.6.28 through 2.6.32, FAT just was written to discard unconditionally. Since 2.6.33, you can control whether it does or not.

As for the FITRIM ioctl, well, that became a thing in 2.6.37, but I do not see any sign that the FAT filesystem code supports it, even in the latest, greatest (as of today) 4.13rc5. Several other filesystems have implemented it, but no one seems to have bothered for FAT.

That's sort of too bad, because there's at least one perfectly common scenario where you would want a way to TRIM all the existing free blocks at once: you've given your ancient Banana 6000 a nice upgrade by dd-ing the full disk image from the old spinning drive to a shiny new SSD, so now, as far as the SSD is concerned, all of those blocks have been written, whether they matter to the filesystem or not. So, of course, you'd like the ones considered free by the filesystem to be trimmed.

But there may be hope. While I haven't had a chance to try it yet, I think this might work:

  1. Mount the filesystem (be sure to use -o discard).
  2. Create some empty files.
  3. Blow those up to the maximum possible size using fallocate -n (which allocates the blocks without writing anything to them, so will not put much extra wear on the SSD). For FAT32 a file is limited to just under 4 GiB, so that's why you may need a bunch of temporary files to use up all the free space. (For this step to work, you need kernel 4.5 or later, where FAT has fallocate support.)
  4. Once you've filled all free space, get rid of the temporary files, letting all the freed blocks be discarded.

This, of course, ought to work as a brute-force fstrim alternative for any filesystem implementation that is able to do discard but not FITRIM.

p.s. I do like the alternate links offered below in Tom Yan's comment. I was working from the more-or-less official git repo, but what I like about the service Tom linked to is that you can more easily switch between different versions of a file to compare.

Related Question