How vim Prevents Blowing Up Your SSDs?

#programming #linux #vim #softwareengineering

The other day, I was going through a list of useful UNIX commands and came across tail -f. The tail command, by default, shows the last 10 lines of a file, but you can use the -n option to see a specific number of lines.

The tail -f command, however, lets you watch a file for live changes. I decided to try it out by watching a file named hello.txt in the terminal while editing it using Vim.

But to my surprise, no changes appeared in the output of tail -f.

This made me curious, and I started digging into what was happening. That research led me to some really interesting concepts — and made me appreciate how smart Vim’s design actually is.

What Is `tail -f` Really Doing?

To begin with, let’s understand what tail -f does. It watches a file using its inode — a data structure in UNIX-like systems that stores metadata about files. Now, when I edited hello.txt using Vim, something unusual happened behind the scenes.

Unlike many other text editors, Vim doesn’t directly overwrite the original file. Instead, when you save (:w), it creates a temporary file, writes the changes to it, and then renames that temp file to the original file name. This also changes the file’s inode, because it’s technically a new file now.

Why Does Vim Do This?

Because it was designed with data safety in mind.

If there’s a sudden power loss or crash, the original file is untouched unless the temp file is successfully written and renamed. It’s a smart fail-safe.

How SSDs Work Under the Hood?

This behavior reminded me of what I learned about modern SSDs in my computer organization class.

SSDs store data in small units called pages (typically 4 KB), and these are grouped into larger blocks (typically 128–512 KB). Every page is mapped to a Logical Block Address (LBA).

Now here’s the catch: although SSDs can write to a page easily, they can’t delete just a page. To delete anything, they must erase the entire block that contains it.

💡 So writing (write()) is cheap, but deleting (delete()) is expensive.

What About Editing or Overwriting?

SSDs don’t really overwrite. Instead, when you update a file, the system writes the new version to a new block, and marks the old one as stale. The garbage collector eventually comes along and erases the stale blocks — but not immediately. It works lazily in the background.

Before erasing a block, the garbage collector has to check whether there’s still valid data in it (from other files). If so, that valid data is copied to a new block first. This leads to write amplification — writing more data than you originally intended.

It’s like moving out of a shared apartment. Even if you’re ready to go, your roommates’ stuff still has to be moved before the landlord can clean the place.

Every write on an SSD wears out its NAND flash cells. These cells have a limited number of write-erase cycles — just like a whiteboard that gets dull with too much writing and erasing.

Vim’s Design = SSD Friendly

Vim avoids overwriting files by creating new ones. This:

Minimizes write amplification
Reduces SSD wear
Prevents direct inode overwrites

Since a new file is created, the inode changes, which is why tail -f doesn’t detect Vim’s changes.

Here’s the key difference: Vim writes a new file, and the garbage collector cleans up the old one later.

But when you use modern editors or write to a file using echo "hello" > hello.txt, it overwrites the existing file in-place, on the same inode.

This forces the SSD to mark blocks stale immediately and can wear out specific NAND cells over time.

What’s the Fix?

Use tail -F instead of tail -f.

The -F option watches the filename, not the inode.

So even if Vim replaces the file, it still detects the update.

TL;DR: How Vim Prevents Your SSD from Blowing Up

Vim doesn’t overwrite files — it creates a temp file, then renames it.
This changes the inode, so tail -f misses updates (use tail -F instead).
New file = less write amplification = less SSD wear.
In-place edits (like echo > file.txt) hit the same inode and trigger garbage collection early.
That stresses the same NAND cells repeatedly, wearing them out.
Vim avoids this by always writing fresh, extending your SSD’s life quietly.

Compared to many modern editors that overwrite in-place, Vim is safer — both for your data and your hardware.

If you ran a write loop using > in a script, you’d dramatically increase SSD wear.