Does TRIM work with FAT32?

Question

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.

Solution 1

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.

Solution 2

The following file systems support TRIM: NTFS, HFS+, EXT4, Btrfs.

Many operating systems now offer TRIM support, which is designed to improve write performance. TRIM allows a NAND flash device's controller to manage the erase process after data is deleted from a cell and before the next write to that cell occurs.

Linux started supporting TRIM back in late 2008, but not all file systems supported by Linux support TRIM. Microsoft Windows started to support TRIM in late 2009 with Windows Server 2008. OpenSolaris began supporting TRIM in the middle of 2010. Android for mobile devices just started to support TRIM in 2013.

So, at this point, many but not all major operating systems support TRIM, which is currently available for SATA interfaces only.

TRIM (also spelled trim) is a specific command in a serial ATA (SATA) interface that tells an underlying NAND flash solid state storage device which data it can erase. TRIM, which conceptually can be compared to a defrag utility on a spinning hard drive, improves performance by pro-actively freeing up space.

NAND flash memory organizes data into pages, and pages are grouped together in blocks. Data can be read and written at the page level but can only be erased at the block level. When data is deleted from flash media, the associated pages on the solid-state drive are flagged for deletion, but not erased -- because only blocks can be erased. When a new file is written, individual pages marked for deletion are grouped into a block so they can be erased first, making room for the next write.

The TRIM command allows the operating system to notify the solid state drive (SSD) which data in a particular set of pages can be overwritten, allowing the solid state drive’s controller to manage the erase process between the time when the host initiates a delete and the next write. By moving erasing out of the write process, writes can be faster.

In order for TRIM to function, the host’s operating system (OS) and storage drivers must support the TRIM command. Here's how the TRIM SSD relationship works. In a Windows 7 environment, for example, when the solid state drive reports it has TRIM support, the operating system will disable disk defragmentation and enable TRIM. Then, when a file on the host’s SSD is deleted, the OS sends a TRIM command to the flash controller telling it which blocks can be deleted. TRIM can also be initiated manually by the user or scheduled on a daily basis.

TRIM, which is a command and not an acronym, is currently available for SATA interfaces only. The SAS committee has added UNMAP, which is similar to TRIM, to the SAS/SCSI specification.^{Leah Schoeb}

EDIT

A Trim command allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.

A TRIM command enables your operating system to find the marked pages before you need them and wipe them clean. Cleaning these data pages beforehand saves you time when you need to write on the data pages again. It's like you have your own recycling guy next to your desk, recycling the pieces of paper as they come.

In order to work correctly, TRIM has to be supported by both the solid-state drive and the operating system you are using. When both the OS and the SSD support TRIM individual pages can be cleaned and your solid-state drive will be informed that the pages are now blank and can be written on.

Not all file systems make use of Trim. Among the file systems that can issue Trim requests automatically are Ext4, Btrfs, FAT, GFS2 and XFS. However, this is disabled by default due to performance concerns,

Microsoft claims that, TRIM has only been implemented on NTFS on Windows 7.

Solution 3

Accordind to the changelog for 2.6.33 from Linux Kernel Newbies:

FAT: make discard a mount option

and Wikipedia:

Trim requests automatically are Ext4, Btrfs, FAT, GFS2 and XFS.

So yes, it is supported. But to make sure apply the test from the answer to this question.

UPDATE:

Smecki has done the test and confirmed (see comments) that TRIM is working on FAT32 volumes.

Comments

[David Foerster]

Why do you need a FAT32 file system on an SSD? There is no combination of two major operating systems that doesn't share a sufficiently well supported file system with trim support (at least for internal storage devices; Windows is a bit picky when it comes to removable ones).

[falconer]

TRIM is only supported for NTFS under Windows. Under Linux it is not supported.

[Mitch]

I know that.... Just listed all OS's that support TRIM :)

[falconer]

I don't think that it is the file system what supports trim, it is the file system driver which has to support it. So there is no such thing as NTFS supports it. The windows NTFS driver supports it, the Linux NTFS driver (ntfs-3g) not.

[Bob]

To add on to what @falconer said - TRIM is not inherently tied to any file system. It is a command defined by the interface, SATA. It is sent by the system's I/O interface (SATA) driver/module/whatever. However, a TRIM command can only be sent when a block is known to be empty - and that would depend on the filesystem-specific driver/module in the OS. In other words, it's completely implementation-dependent, and there's nothing technically preventing TRIM support on FAT32.

[Mitch]

@Bob you said "and that would depend on the filesystem-specific driver/module in the OS." Microsoft claims that, TRIM has only been implemented on NTFS on Windows 7. Plus technically I didn't see any confirmation that it works on FAT32. Plus the OP just wanted to know if it works with FAT32.

[Mitch]

@falconer TRIM is supported by both the OS, and the SSD.

[Mitch]

@Bob I understand, and I'm not implying anything, just wanted to clarify it :)

[Smecki]

I tried the test but stalled when I got to "From the output copy the number under begin_LBA". The output gave me: tempfile: filesystem blocksize 4096, begins at LBA 999424; assuming 512 byte sectors. In addition there are 9 sets of numbers under begin_LBA. Which set do I use?

[falconer]

The first one from the begin_LBA column is good. (If you get more output that just means that the file is fragmented on your drive. But don't use that 9999424, thats just where your partition starts.) And don't forget if you use fstrim instead of discard, to run fstrim before sync.

[Smecki]

Test reports that TRIM is trimming. Me and my SSD are mighty relieved. Thanks for your help.

[Tom Yan]

Not bad of an answer. I would suggest replacing the two links in your answer with these though: elixir.free-electrons.com/linux/v4.12/source/fs/fat/… elixir.free-electrons.com/linux/v4.12/ident/FITRIM