Arch Linux

Smoerrebroed

Member

From: Germany

Registered: 2011-07-24

Posts: 106

Trim for FAT/FAT32?

Hi All,

usually I have little need to do anything about my Arch system in general. It normally "just works". However, once in a while I feel the urge to do something, and this time is now - preceding the swap of a SATA SSD to a (larger) NVMe type.

So far I have been running a basic layout with two partitions (EFI formatted as FAT32 and / formatted as ext4) both using the discard mount option. Now I would like to switch to fstrim (at least for the main partition) and was wondering whether FAT32 can also be switched to scheduled trimming. As per the Arch wiki, it cannot: https://wiki.archlinux.org/index.php/So … Drive#TRIM

However, I find hints that also FAT32 does nowadays support scheduled trimming via fstrim: https://askubuntu.com/questions/391101/ … with-fat32

I fail to find any source of information that precisely documents this or gives any indication as to when this functionality was added. Do any of you have any idea (1) whether it is actually true and (2) when fstrim support was introduced to FAT32 under Linux? Any pointers will be highly appreciated.

TIA

Smoerrebroed

Smoerrebroed

Member

From: Germany

Registered: 2011-07-24

Posts: 106

Re: Trim for FAT/FAT32?

Anyone?

At least it seems that with my current setup, fstrim claims that FAT32 does not support trim.

Awebb

Member

Registered: 2010-05-06

Posts: 6,286

Re: Trim for FAT/FAT32?

Your "hint" is a Wikipedia quote without a source.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: Trim for FAT/FAT32?

For me (kernel 4.15.2), fstrim does not work, but discard mount option does work. That's the same as your links claim.

To support fstrim, the filesystem driver has to be able to identify all (or, well, the vast majority) of blocks that are currently free and thus safe to trim. It is a different operation compared to just trimming a single file as you delete it.

Depending on the complexity/implementation of a filesystem, this information can be obtained instantly or only by walking through all sorts of filesystem structures, in which case a dev might decide it is not worth the trouble.

For proprietary filesystems you have another problem: we might simply not be able to understand all aspects of a filesystem. The driver might be able to safely (but not performantely) read files (and sometimes even write). But in order to decide whether it is safe to TRIM for every sector in the filesystem, you need a lot more confidence. Otherwise you TRIM and your own filesystem driver might be fine with it, but once you boot Windows it complains about something missing.

Last edited by frostschutz (2018-04-20 10:49:12)