Every read and write to a spinning disk or SSD costs you something — on HDDs it’s latency, on SSDs it’s endurance. Linux desktop systems write more than most people realise: access timestamps on every file read, verbose system journals, /tmp files that don’t need to outlive a session. Most of these writes serve no practical purpose on a desktop machine. This guide covers five tweaks for Debian and Ubuntu (22.04, 24.04, and derivatives) that reduce disk I/O without breaking anything you care about.
:::note[TL;DR]
- Add
noatimeto/etc/fstab— eliminates timestamp writes on every file read - Switch
systemd-journaldto volatile storage — logs live in RAM, not disk - Mount
/tmpastmpfs— temporary files never touch the drive - Lower
vm.swappinessto 10 — keeps data in RAM longer before swapping - Use
zraminstead of a swap partition — compressed RAM swap with zero disk writes :::
Does Linux really write to disk just from reading files?
Yes. By default, Linux updates a file’s atime (last accessed timestamp) every time a file is read. Reading a 1MB config file writes metadata back to disk. On a desktop with constant file reads, this adds up.
Most distros now default to relatime (only update atime if it’s older than the file’s modification time), which reduces this. noatime eliminates it entirely.
Edit /etc/fstab and add noatime to your root partition entry:
UUID=your-uuid-here / ext4 noatime,errors=remount-ro 0 1Apply without rebooting:
sudo mount -o remount /Do the same for any other mounted partitions (home, data drives). noatime also implies nodiratime — you don’t need to specify both.
The Scenario: You’re running a laptop with an older SSD that’s accumulating write cycles. You’re not doing anything heavy — just browsing, editing text, reading files. The
noatimechange cuts idle background writes noticeably. The SSD health score insmartctlstops climbing quite as fast.
:::warning
A small number of programs depend on atime (some mail clients, certain backup tools). Check your setup before applying system-wide. For most desktop users this is a non-issue.
:::
How do I stop systemd-journald from writing logs to disk?
systemd-journald is the default logging daemon on Debian and Ubuntu. By default it writes persistent structured logs to /var/log/journal/. On a desktop, you rarely need logs to survive a reboot. Switching to volatile mode stores them in RAM under /run/log/journal/ — gone on reboot, but disk writes drop significantly.
Create a drop-in config file:
sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/volatile.confAdd the following:
[Journal]
Storage=volatile
RuntimeMaxUse=64MRestart journald to apply:
sudo systemctl restart systemd-journaldRuntimeMaxUse=64M caps the RAM the journal can use. On a machine with 16GB+ RAM, 100MB is fine.
If you want logs on disk but at reduced volume, keep Storage=persistent and add size and level caps instead:
[Journal]
SystemMaxUse=100M
MaxLevelStore=warningMaxLevelStore=warning drops info and debug messages from hitting disk entirely — only warnings, errors, and criticals are persisted. This cuts journal write volume dramatically on verbose systems.
The Scenario: You check
iotopand seesystemd-journaldconsistently near the top of disk write activity. Switching to volatile drops it off the list entirely. Your system feels snappier because the I/O scheduler has less to compete with.
Should I mount /tmp as tmpfs?
Yes, unless you generate large temporary files that won’t fit in RAM. Modern Debian and Ubuntu both default to mounting /tmp as tmpfs (a RAM-backed filesystem). Verify yours:
findmnt /tmpIf the output shows tmpfs under the FSTYPE column, you’re already set. If it shows your disk partition, add this to /etc/fstab:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0For /var/tmp (temporary files that survive reboots by convention), you can do the same if your workflow doesn’t depend on them surviving:
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0Reboot or remount to apply:
sudo mount -a:::warning
/tmp as tmpfs uses RAM proportionally to what’s stored in it. If something writes large files to /tmp (video editors, compilers), they’ll consume RAM instead of disk. The default size limit is half your physical RAM. Adjust with size=2G in the mount options if needed.
:::
How do I reduce swap writes on an SSD?
The kernel’s swappiness setting (default: 60) controls how aggressively it moves RAM pages to swap. A value of 60 means it starts swapping fairly early. On a machine with plenty of RAM, this is wasteful — you’re writing to disk when you have free memory available.
Lower it in /etc/sysctl.conf:
vm.swappiness=10Apply immediately without rebooting:
sudo sysctl -pA value of 10 tells the kernel to strongly prefer RAM. On systems with 16GB+ RAM you can go as low as 1. Don’t set it to 0 — that can cause OOM kills instead of graceful swapping under memory pressure.
What is zram and should I use it instead of a swap partition?
zram creates a compressed RAM-backed block device used as swap. Instead of swapping pages to disk, they’re compressed and stored in RAM. Write endurance on your SSD is preserved entirely, and swap performance is dramatically faster.
Ubuntu 22.04+ ships with zram-config enabled by default. Verify:
zramctlIf it shows a /dev/zram0 device, it’s active. On Debian or Ubuntu without it:
sudo apt install zram-toolsConfigure in /etc/default/zramswap:
# Use 50% of RAM for zram swap
PERCENT=50Restart the service:
sudo systemctl restart zramswapCheck it’s working:
free -h
swapon --showThe Scenario: Your laptop has 8GB RAM and an NVMe drive. Previously, swap writes showed up in
iotopduring heavy compilation jobs. With zram, those writes disappear — swap is happening entirely in compressed RAM. Compile times improve too, because RAM access is faster than even NVMe.
:::warning
zram reduces SSD writes but adds CPU overhead for compression/decompression. On low-power CPUs (older Atom, ARM) this can be measurable. On any modern x86_64 processor it’s negligible — compression is hardware-accelerated.
:::
Are there any other quick wins for reducing disk writes?
Dirty write-back tuning — the kernel batches writes and flushes them to disk periodically. The defaults are conservative. For a desktop you can push dirty data to flush less frequently:
# /etc/sysctl.conf
vm.dirty_writeback_centisecs=1500
vm.dirty_expire_centisecs=3000This tells the kernel to wait 15 seconds between write-back scans and let dirty pages age 30 seconds before forcing a flush. More data is batched per write, fewer total I/O operations.
Apply with sudo sysctl -p.
Browser profile on tmpfs — browsers write constantly to their profile directories (cache, session data, IndexedDB). Moving the browser cache to /tmp (already on tmpfs) or a dedicated RAM mount eliminates this entirely. Extensions like profile-sync-daemon (available in Ubuntu repos) automate this.
Summary
noatimein/etc/fstab— one-line change, safe, immediate benefit on any filesystem- journald volatile —
Storage=volatilein a drop-in config drops log writes to zero on disk /tmpas tmpfs — verify it’s on already; if not, one/etc/fstabline fixes itvm.swappiness=10— keeps RAM in use longer, reduces swap thrash on SSDs- zram — best option for swap: zero disk writes, faster than any SSD, minimal CPU cost on modern hardware
- dirty write-back tuning — small incremental gain, safe on desktop, one
sysctl.confentry
FAQ
Will these changes break anything?
The noatime and swap changes are safe on virtually every desktop setup. Volatile journald means losing logs on unexpected reboots — only relevant if you’re debugging intermittent crashes. /tmp as tmpfs can cause issues if an application writes large files there and you’re low on RAM.
Do these tweaks help SSDs more than HDDs? Both benefit, but for different reasons. HDDs benefit from reduced seek operations. SSDs benefit primarily from reduced write cycles, which directly affects drive lifespan. NVMe drives in 2026 have high write endurance, but the habit is still good.
How do I verify how many disk writes are happening?
Use iotop for live I/O monitoring:
sudo apt install iotop
sudo iotop -aoThe -ao flags show only active processes and accumulate totals, making it easy to see which processes are the biggest disk writers.
Can I apply all of these at once?
Yes. They don’t conflict. Apply noatime and dirty tuning via sysctl/fstab, switch journald to volatile, and set up zram — then reboot to confirm everything came up clean.
Does zram replace swap entirely? It can. If you have 16GB+ RAM and don’t run memory-intensive workloads, disabling the disk swap partition and relying solely on zram is reasonable. For machines with 8GB or less, keep a fallback swap partition in case zram itself fills up under extreme load.
What to Read Next
- Install Docker on Ubuntu, macOS, and Windows
- How to Exit Vim, Vi, and Nano
- Install Git on Ubuntu, macOS, and Windows
