Groups | Search | Server Info | Login | Register

Groups > uk.comp.os.linux > #23750

TRIM (Was: Here we go again)

Show all headers | View raw

On 08/09/2025 17:28, Davey wrote:
> I have not heard of fstrim, now that I know about it, I will look at
>   it and implement it.

Trimming SSDs used to be talked about a lot, when SSDs were new and 
exciting, and many times the cost per MB of HDDs. Now, not so much.

The issue is that each block of storage on an SSD can only reliably be 
written a finite number of times - generally of the order of several 
thousand. This is where the "Terabytes Written" lifetimes quoted for 
SSDs comes from. The controller of an SSD tries to minimize this "wear" 
by writing new data to the least-used available block ... but to do this 
it has to know which blocks are "available".

The more blocks that are available the more effective the wear-levelling 
strategy employed by the SSD controller can be. If a disk is only 
part-full, or if the disk uses "over-provisioning" (keeping some blocks 
in reserve and advertising itself as a smaller disk than it could be) 
there is often no problem. As a disk fills up it is more likely to be a 
problem.

The position is slightly complicated by the fact that SSD blocks are 
larger than disk sectors (for hardware reasons) so many sectors share 
the same block, and that SSD blocks can only be written in their 
entirety -- several sectors must be written at once.  The problem of 
finding "available" blocks becomes harder as the disk comes to contain 
more and more blocks that are only partly used, so the controller uses a 
"garbage collection" technique to collect up data from part-used blocks 
and move them to a new block, making the blocks that data came from 
available for future writes.

When a file is edited (say) the OS may write the new version in the same 
place on disk (the same actual disk sectors) or may write the whole 
changed file out somewhere else (different software works in different 
ways). In the former case the SSD controller has to remap the sectors 
onto different blocks and allocate new clean blocks for the new data, 
but it then knows that the old blocks that used to be mapped to those 
sectors are available for reuse. In the latter case the controller knows 
that the OS has told it to use some new sectors, but doesn't know that 
the OS now considers the old sectors to be unused, so it continues to 
regard them as "unavailable".

On early SSDs this was a problem. Then the TRIM command was added to the 
ATA interface, enabling an OS (more accurately a filesystem, in the 
Linux world) to tell the SSD controller that it is no longer using a 
particular sector. This enables the controller's wear levelling to run 
more efficiently, and so prolongs the life of the SSD.

Ideally, you'd like the filesystem to tell the SSD that a sector is 
unused as soon as it becomes so - e.g. when a file is rewritten to a 
different location and the old one deleted ... or on any file deletion 
or truncation. Unfortunately it seems that some old/cheap/shitty SSDs 
can't cope with TRIM commands occurring in the middle of a lot of file 
i/o and these SSDs may suffer errors or slow down if the filesystem 
issues its own TRIM commands (I've never seen it happen, but the 
Internet can't be wrong[Citation needed]) so it's not done by default.

You can enable automatic filesystem TRIM commands by adding the 
parameter "discard" to the mount command for your SSD ... e.g. in 
/etc/fstab. This works for Ext3, Ext4 and some others ...

Note that a TRIM command is just a simple command that says "Treat 
Sectors x-y as unused". It's housekeeping information for the controller 
and doesn't actually write to the SSD (though the controller will 
probably return blank data if anyone tries to read an unused sector, 
whatever is actually in the Flash memory).

The fstrim commandline tool is an alternative to enabling TRIM in the 
filesystem driver. When you run fstrim the program analyses the 
filesystem and works out which sectors of the disk are actually in use. 
It then uses the TRIM command to tell the SSD about ALL the others (most 
of which it knows about anyway). The filesystem driver may be clever 
enough (Ext4 apparently is) not to allow unnecessary TRIM commands to be 
sent when fstrim is run multiple times between boots, but will start 
afresh after a reboot.

At the end of the day, though, it's not a big deal. All reputable SSDs 
are designed with the assumption that TRIM commands may not be used at 
all; they have sufficiently good wear-levelling and sufficient 
over-provisioning that they will work well enough without TRIM. That's 
not to say that TRIM won't help, just that life can go on without it.


-- 
Cheers,
  Daniel.

Back to uk.comp.os.linux | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Here we go again Davey <davey@example.invalid> - 2025-09-02 11:03 +0100
  Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 08:57 +0100
    Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-03 16:49 +0100
      Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-03 17:21 +0100
        Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 17:48 +0100
          Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-03 18:20 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 20:10 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 20:50 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 11:35 +0100
              Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-04 17:30 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 19:52 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-05 23:49 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-08 11:50 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-08 16:11 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-08 17:28 +0100
                TRIM (Was: Here we go again) Daniel James <daniel@me.invalid> - 2025-09-15 16:00 +0100
                Re: TRIM (Was: Here we go again) Davey <davey@example.invalid> - 2025-09-15 17:30 +0100
                Re: TRIM Richard Kettlewell <invalid@invalid.invalid> - 2025-09-17 08:43 +0100
                Re: TRIM Daniel James <daniel@me.invalid> - 2025-09-17 10:30 +0100
                Re: TRIM Davey <davey@example.invalid> - 2025-09-17 11:05 +0100
                Re: TRIM Daniel James <daniel@me.invalid> - 2025-09-17 15:12 +0100
                Re: TRIM Davey <davey@example.invalid> - 2025-09-17 15:54 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-09 09:04 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-09 12:19 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-09 18:03 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-09 22:02 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-10 00:14 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-11 17:12 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-21 16:10 +0100
                Re: Here we go again -Update "Vincent Coen" <VBCoen@gmail.com> - 2025-09-22 01:41 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-22 09:29 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-10 12:43 +0100
                Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-08 21:33 +0100
              Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-04 20:07 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-05 02:47 +0100
          Re: Here we go again Gordon <Gordon@leaf.net.nz> - 2025-09-03 23:46 +0000
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 09:36 +0100
        Re: Here we go again Gordon <Gordon@leaf.net.nz> - 2025-09-03 23:31 +0000

csiph-web