Your Linux desktop (especially Pop!_OS or Ubuntu) randomly freezes under heavy write loads. Browsers lock up when downloading files, IDEs (like IntelliJ or VS Code) stutter during indexing, and compiling code brings the system to a halt.
Before applying this fix, test your raw SSD write speed. We will write a 5GB file using direct I/O to bypass your RAM cache and measure the actual silicon speed.
Run this command in your terminal:
dd if=/dev/zero of=test_write_file bs=1G count=5 oflag=direct(Don't forget to delete the test file afterward: rm test_write_file)
The Reality Check: If you are using a modern QLC-based SSD (like the Samsung 870 QVO) rated for 500 MB/s, you might see this benchmark return something like 30 MB/s (slower than a 15-year-old mechanical hard drive).
If you enabled Full Disk Encryption during your OS installation, your drive is likely suffering from a blocked TRIM command.
QLC drives rely on a fast "SLC Cache" (using empty storage space) to achieve high speeds. When you delete a file on Linux, the OS normally sends a TRIM command to tell the SSD it can reuse those blocks for its fast cache.
However, Linux blocks TRIM commands through LUKS encryption by default for security reasons. Because the SSD never receives the TRIM command, the hardware thinks the drive is 100% full of undeleted data. The fast cache shrinks to zero, and the drive is forced to write directly to the slow QLC memory, causing your entire OS to freeze while it waits for the disk.
Run this commands to confirm you are affected:
1. Check if TRIM is blocked:
sudo fstrim -v /If this returns fstrim: /: the discard operation is not supported, proceed to step 2.
2. Check if your root drive is encrypted:
lsblk -fLook at your root partition (/). If it is nested under a crypto_LUKS tree, this fix applies to you.
To fix this, we need to explicitly allow the discard (TRIM) command to pass through the encryption layer.
(Note: This has a minor security tradeoff, as an attacker with physical access to your drive could theoretically determine exactly how much free space you have based on empty blocks. For 99% of desktop users, this is worth the massive performance gain).
Step 1: Edit your Crypttab Open the cryptography table configuration file:
sudo nano /etc/crypttabFind the line corresponding to your encrypted drive (usually named cryptdata). Add ,discard to the end of the options string.
It should look something like this:
cryptdata UUID=xxxx-xxxx-xxxx none luks,discard
(Save and exit: Ctrl+O, Enter, Ctrl+X)
Step 2: Rebuild the Boot Image Because the drive is unlocked during boot, you must update the initial ramdisk so the system knows about the new rule before the OS loads:
sudo update-initramfs -u -k allStep 3: Reboot You must restart your computer for the encryption layer to reload with the new rules.
Step 4: Dump the Garbage Once you log back in, manually trigger the TRIM command to clear out months/years of dead data:
sudo fstrim -v /Note: This might take a few minutes. It should report back that it trimmed many Gigabytes of data! In my case it was ~570Gb!
Step 5: Enable Automatic Weekly Maintenance Ensure the background systemd timer is enabled so Linux does this for you automatically in the future:
sudo systemctl enable --now fstrim.timerRun the dd benchmark from the beginning of this guide one more time:
dd if=/dev/zero of=test_write_file bs=1G count=5 oflag=directOn a 1TB Samsung 870 QVO, this fix took write speeds from 30.9 MB/s back up to 498 MB/s (a 1,600% increase), completely eliminating all system stuttering and lockups.
Thank you for this guide. I couldn't find any clear answers on this problem on any Pop!_OS-related forums and I struggled with this issue for many months. I genuinely thought it was some firmware or hardware issue with my laptop. Now my write speeds jumped from about 46 MB/s to 1.1 GB/s. That's over 2300% increase!