TRIM and file fragmentation on an SSD

Question

I ran the TRIM test proposed by frostschutz and also found here. The result 1MB file is highly fragmented. How can that be ?

My one and only storage device /dev/sda is a Samsung 500GB SSD. It is "TRIM-ready" and the kernel comes with an fstrim executable in /etc/cron.weekly. I nevertheless wanted to run the test, say, out of curiosity. The test produced a 1MB file, trim.test, filled with the y alpha character.

Following the file creation I checked the file's exact position on disk:

> cd /
> yes | sudo dd iflag=fullblock bs=1M count=1 of=trim.test
> sudo filefrag -s -v trim.test

Filesystem type is: ef53
Filesystem cylinder groups approximately 177
File size of trim.test is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      15:    2816076..   2816091:     16:             merged
   1:       16..      31:     170064..    170079:     16:    2816092: merged
   2:       32..      63:     170848..    170879:     32:     170080: merged
   3:       64..     127:     168269..    168332:     64:     170880: merged
   4:      128..     255:     170112..    170239:    128:     168333: merged,eof
trim.test: 5 extents found, perfection would be -1 extent

This repeats itself if I erase the file and repeat the procedure. How can a 1MB file be so heavily fragmented ?

Answer 1

After snooping around and readings on the matter of TRIM and fragmentation, answering my own question might be of help to others.

Reading about TRIM, frequent references to file fragmentation are made. Both aspects are the source of legitimate questions about SSD storage performance, however the 2 issues are distinct.

• file fragmentation consists in one file being written to HDD or SSD in many different non-contiguous write-areas, using physical blocks distributed over the storage medium within a partition. In the particular context of SSDs, we will see it has nothing to do with TRIM's actions or even with TRIM's level of storage management, but that it is related to wear-leveling (WL), another process for low level storage medium management always present in SSDs (unlike TRIM). Internal data management in SSDs is fundamentally different from that of HDDs in its assignment o sectors to non-volatile flash memory cells (i.e. SSD's cells) and their corresponding blocks (flash blocks). It has a direct incidence on file fragmentation.
• TRIM prepares at-least-once written physical blocks on an SSD for new write operations (Wops), obviating the need to actually erase the targeted blocks immediately before the Wop occurs (as would be the case in a setup w/o TRIM). For that the SSD must have a hardware controller that is TRIM-ready. It is not always the case. After the first phase of use (i.e. when the SSD is still relatively new and all its blocks have not yet been written over at least once), Wops slow down until they reach a speed plateau. At that stage, a rule of thumb is that TRIM approximately halves write-times on TRIM-ready SSDs with respect to the same hardware without TRIM enabled.

During Wops, SSDs behave quite differently from HDDs. An HDD will never need erasing of a block prior to a Wop. An SSD always does and that is time consuming. TRIM helps alleviate that time consumption by pre-conditioning recently freed blocks on the TRIM-capable SSD, essentially by pre-erasing blocks that are freed after a file was modified and moved to a different area of the volume. This is a simplified view of reality, but one that the non-expert user can roughly rely on to begin to make decision about hardware and low level hardware administration. Read on...

Is TRIM related to SSD's fragmentation ?
- Short answer: No, they are not related.
- Long answer: Fragmentation is related to wear-leveling (WL), yet another process that optimizes the life span of SSDs. WL is essential to homogenize Wops over the whole SSD's free/available/unreserved block space inside a volume/partition. It does so, because each Wop makes the corresponding SSD's cells age, through the application of a relatively large voltage over a tiny area of semiconductor layer, thereby reducing its life span. (I believe, this has to do with thermal induced defects introduced in the bulk of the SSD, but that's off-topic.)

If Wops were managed on SSDs as they are on HDDs, certain areas of the storage medium would wear out long before others, leading to non-operable blocks, loss of capacity , loss of data and errors. WL actually ensures that all blocks in any given SSD's partition are subjected to the same amount of Wops and that the wear is "leveled out" over the entire SSD's available partition space. In that sense, it effectively increases the life span of the SSD, while maintaining its full capacity until its demise.

There are two WL modes: static and dynamic. This wiki (in German) specifies that write-cycle counts at SSD's end of life may increase 100 fold for static and 25 fold for dynamic WL as compared to the same hardware with WL turned off.

As WL physically distributes Wops (the limiting parameter that defines the life span of SSDs) as uniformly as possible over the entire SSD's storage space inside a partition, it will inevitably contribute to its data fragmentation. It does so, in order to achieve its prime objective of optimized distribution of written blocks throughout any given SSD's partition. The uptake is that any file stored on an SSD may be fragmented quite a bit more than it would on a traditional HDD. Fragmentation however does not translate in any performance decline for the SSD.

How WL operates has other corollaries: the bigger the SSD volume, the greater its life span for given conditions of use. For the user, "conditions of use" mean primarily:
- the amount of used space on an SSD's partition and
- Wop's frequency, i.e. how heavily write-accessed is the storage medium.
This actually may speak in favor of :
- placing the lx swap, /home, /tmp and /var on an HDD, while the rest of the OS may live on happily on a smaller SSD.
- not making any partitions with a lot of Wops too small on an SSD. For instance if swap must be on an SSD and you read that the lx-swap is best set at twice your DRAM size, make it 4 times. I don't know whether my arythmetic is right, but the general idea is that this will also more or less double your swap space life-span. If you conduct a lot of operation that require swapping (servers with heavy usage DB, etc.), think about moving your swap and /tmp onto an HDD, unless you like the idea of taking a gas burner to your SSD of course.

Meanwhile TRIM prepares SSD's blocks for any upcoming new Wop. It pre-conditions once written cells for a new Wop by erasing those cells (actually the operation occurs at the level of a block) and starting garbage collection when needed. In that sense TRIM keeps an eye on the distribution map of newly freed (and at least once used) blocks as they are being low-level managed by the WL controller.

Conclusion:

• Fragmentation is no matter. It is not detrimental to the SSD's performance. SSDs do not need (see Intel's talk on SSDs) nor do they benefit from housekeeping in the form of defragmentation. Whatever your OS, turn defrag off. Now.
• TRIM is important and beneficial, provided the SSD is TRIM ready. Today a handful of brands provide TRIM capable SSDs. If you have read this thread from the beginning you know the name of at least one of those reputable brands. Also few years ago, ext2 was considered the better option over ext3 because journaling actually went against some of the benefits brought about by TRIM when using 1st generation SSDs. It is not the case anymore and ext4 is actually advised with TRIM + Garbage Collection.

HTH.