All write operations reduce the life of the SSD. I use 50 GiB volumes on a 4x NVMe RAID-Z1. Each drive is rated for 3500 TBW. I also only call this script when I want to reclaim space, such as after downloading many large dependencies for a one-time build. My home use case is read-heavy, so I'm really not concerned. When one drive goes, I can replace it. If they all go at once: I have remote encrypted B2 backups.
I always read (from sources like LKML, not random blog posts) that defrag on SSD is simply useless because you never know the actual physical placement of your blocks. You can write a sequential 512 MB chunk of data in a single file and have it exploded in 500k+ 4k blocks in different locations (or vice versa — a bunch of random writes to different sectors can be compacted into a single linear block).
If you really need to defrag SSD (which somewhat helps IME if it was heavily used up to 100% capacity), copy everything to other storage, wipe it (preferably with NVMe/SATA commands, or at least do a full TRIM), and then copy everything back.
if your first assertation is correct, and ssd's use internal mapping of physical and logical sectors, then your suggestion with wiping/rewriting would not work.
i know that per SMART, disks (hdd and ssd) have to have extra space that will be used if an active sector goes bad, but idk about the total internal remapping on ssd's.
TRIM is a solution to a different problem. This is a higher layer operation that saves storage usage regardless of the media. I hardly consider any an operation where I understand the tradeoffs a "big no no". I'm an engineer, not a six-year-old.
Trim is not supposed to help with ZFS compression, it occurs at a layer below what the FS sees (but the FS hooks are necessary for the controller to understand the logical use).
The issue TRIM helps with is the following: while reads and writes are performed at the page level (2-16k), a page can not be overwritten (it can only be written to when empty) and an SSD can only erase entire blocks (128~256 pages).
This means when you perform an overwrite of a page, the SSD controller really has an internal mapping between logical pages (what it tells the FS) and physical pages (the actual NAND cells) and it updates the mapping over the overwritten logical page to a new physical page (in which it writes the “updated” data), marking the old physical page as “dirty”.
So as you use the drive the blocks get fragmented, more and more full of a mix of dirty and used pages meaning the controller is unable to erase the block in order to reuse its (dirty) pages. So it garbage-collects pages, which is a form of completely internal defragmentation: it goes through “full” blocks, copies the used pages to brand new blocks, then queues the blocks for erasure.
The issue with this process is… the SSD only knows that a block is unused when it’s overwritten, historical protocols had no more information since the hard drives had the same unit for everything and could overwrite pages, and thus the FS managed that directly. This means if you delete a file the controller has no idea the corresponding pages are unused (dirty) until the FS decides to write something unrelated there, meaning if you do lots of creation and removing (rather than create-and-never-remove or create-and-overwrite) the controller lags behind and has a harder and harder time doing physical defrag and having empty blocks to write to, this leads to additional garbage collection and thus writes, and all the “removed but not overwritten” blocks are still used as far as the controller knows so they’re copied over during GC even though no one can or will ever read them.
TRIM lets the FS tell the controller about file deletions (or truncation or whatever), and thus allows the FS to have a much more correct view of the actually used blocks, thereby allowing faster reclamation of empty blocks (e.g. if you download a 1GB file, use it, then remove it, the controller now knows all the corresponding blocks are dirty and can be immediately queued for erasure) and reducing unnecessary writes (as known-dirty pages don’t have to be copied during GC, only used pages).
> Trim is not supposed to help with ZFS compression, it occurs at a layer below what the FS sees
The problem that was described was reclaiming space from a VM. I took the comment about compression ratios to be a measurement of the entire VM disk image, because otherwise if you just want a big meaningless ratio then dump a petabyte of zeroes into a new file.
A VM that isn't set up to TRIM will leave junk data all over its disk image, bloating it by a lot. If the guest OS understands how to TRIM, and the VM software properly interprets those TRIM commands, then it can automatically truncate or zero sections of the disk image. If either of those doesn't understand TRIM, then you need to fill the virtual disk with zeroes to get the same benefit. (And possibly run an extra compaction command after.)
This is at a completely different layer from what you elaborated on, because it's a virtual drive. It's good to have virtual drive TRIM even if you're storing the disk image on an HDD! It's a different but analogous use case to real physical drive TRIM.
Its only a problem if the delta between adjacent bits grows too large. "Wear-leveling" is a type of auto-defrag that will shuffle data around intentionally to keep these deltas equivalent. "Program-erase" cycles (the lifetime of the gate oxide layer that you literally destroy) are an order of magnitude less worrisome, and the larger the drive the less this matters.
Your point is that it's pointless to defrag SSDs. Well I'm not. I'm defragging virtual drives, which is not pointless, regardless of the medium. So your point is wrong.
