[SOLVED] 45.3GB trimmed, but no space is recovered

[mole]

I've an NVMe drive that appears to have 45GB "missing":

[krotuss]

fstrim has nothing to do with increasing free space reported by df utility, it merely notifies the drive about which blocks are empty.

As for used, free, total space discrepancy. Difference is about 42.9GB which is about 5%, common amount for reserved space on fs. Although I am not 100% sure that that is really the case and how df reports it on ext4.

[mole]

Yes, I misunderstood what fstrim actually does and was off down a rabbit hole. It was the reserved space as you suggested:

tune2fs showed:

[logrusx]

Add discard option for your root fs in /etc/fstab so that you don't need to run fstrim manually and do not cause unnecessary wear of the ssd. Here's mine:

[irets]

logrusx,

Are there any downsides to having the discard mount option on a SSD root?
Should I always use that?

[NeddySeagoon]

Irets,

That's a hard one. It depends how the SSD firmware implements it's garbage collection.
In some SSDs, it's an immediate instruction, in others, the firmware takes notes and does garbage collection later, when there is lots of it.
It's not easy to tell from the outside.

Immediate garbage collection increases the wear, as the erase block size is much bigger that the read/write block size.
So blocks still in use need to be moved out of the way of the region to be erased.

Using fstrim in a cron job or as a part of your update cycle, puts the actual erasing back in you control, regardless of how the drive implements it.

Its an open question if the excess write amplification makes any practical difference to drive life.
One drive I have has a projected write life of 180 years. I won't care if it's worn out then :)
In 10 years it will be too small/slow/old and bill be replaced. Write life is not the problem it once was.

My first SSD, over 10 years old now, failed in September. Not for write life, for a sudden rash of bad blocks.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[logrusx]

[toralf]

[logrusx]

[Hu]

The drive ought to perform any needed migrations before it reaches the point that it has no free space in which to work. The argument that trim is not necessary is based on the idea that the drive ought to be rated for enough write-erase cycles that even without trim, the drive is removed from service (whether because it dies of electronics failures or is retired for age) before the write-erase load renders it unusable. Whether that will happen in practice depends both on the workload and the quality of the drive. I could believe that certain low end drives have few enough write-erase cycles that a heavy load (such as constantly writing and deleting files, as fast as the drive can handle requests) could kill the drive before it is retired. On the other hand, if a drive is used sparingly (such as a read-mostly workload) or was built to withstand heavy load, it has a good chance of being removed from service before it breaks.

None of this argues that trim cannot improve the situation (assuming the drive's firmware handles trim well; some don't); it only argues that good drives ought to be usable enough even without trim.

[logrusx]

[NeddySeagoon]

logrusx,

[Hu]

I expect that the drive keeps a reserve of sectors that are not addressable by the OS, which it can use as a scratch space during wear leveling because the OS can never make those sectors dirty.

The only benefits to not trimming are (1) if you have an encrypted device and want to make it unclear which areas are free or (2) if your drive's implementation of trim is of such poor quality that trimming causes more problems than it solves. As Neddy mentions, some early drives were bad about taking trim as an immediate command, such that the drive was compelled to set aside all other work and perform the trim immediately. I think I also read about drives that could only handle a trim if no other commands were in the queue from the OS to be processed. There may be other ways in which poor quality implementations made their users unhappy.

[logrusx]

Neddy, Hu, thank you for taking the time to explain and dispel the wrong knowledge I have :)

Best Regards,
Georgi