First, a correction: TBW is not a countdown timer
The original piece opens by saying a "modern 1TB SSD" averages 600TBW and that a 512GB drive should get about half. Don't treat that as a rule.
TBW (terabytes written) is a manufacturer-rated endurance figure. It depends on the specific drive model, its NAND type and the workload assumptions behind the rating. It is also tied to warranty terms. Hitting the number doesn't mean the drive dies, and a smaller drive isn't automatically half of a bigger one's rating. To know your own budget, look up the datasheet for your exact model.
Even the article concedes that most people will never reach their endurance limit through ordinary use. So the realistic goal is trimming waste and reclaiming space, not panicking over every write.
Habit 1: Torrenting everything large
Torrent clients fetch pieces from many peers at once, and the pieces arrive out of order. The client may therefore write to scattered locations in the destination file instead of filling it front to back. Random writes are generally harder on SSDs than sequential ones, and the article ties this to write amplification, where the drive writes more internally than the host sent.
That mechanism is plausible, but the source offers no measurement of how much extra wear a typical torrent causes. The result depends on the client, its preallocation settings and where the files land. Treat it as a possible source of extra disk activity, not proof that torrents damage drives.
The author also mentions a QLC drive (four bits per cell) that developed problems after a few years. QLC drives often have lower endurance than TLC drives, but that is a general trend, not a verdict on every QLC model. The author explicitly says he can't blame torrenting for the failure, and the article gives no drive model or diagnostics. It is an anecdote, not evidence of cause.
Reasonable steps:
- Don't download and unpack large files you don't need.
- For very large, sustained downloads, consider whether they need to land on your system drive.
- Check your client's allocation settings, since behavior varies by client.
Habit 2: Benchmarking over and over
This is the easiest habit to verify. Benchmark tools write temporary test data and delete it. The official CrystalDiskMark documentation lets you pick the number of runs, from 1 to 9 with a default of five. Test sizes run from 16MiB up to 64GiB, with 1GiB as the default. Wait, that detail comes from the tool's own documentation rather than the search results below, so treat the exact defaults as the vendor's published settings. The same page also warns that the tool may shorten SSD or USB memory life.
The article says a single run "can involve several gigabytes" of writes. That is only true for some settings. The real amount depends on the test size, the run count and which tests you select.
Reasonable steps:
- Benchmark when you have a reason, such as validating a new drive or checking after a firmware change.
- Lower the run count or test size if you're only looking for a sanity check.
- Point the test at the drive you actually mean to measure.
Habit 3: Recording gameplay nonstop
The author used Xbox Game Bar to record gameplay in the background, even though he rarely posted the clips. Recording means constantly encoding and saving video, and the file size depends on resolution, frame rate, codec and bitrate.
His example uses 20 Mbps. The arithmetic checks out: 20 megabits per second over an hour is about 9GB, before audio and container overhead. That figure is an estimate, since variable bitrate and capture settings will shift it. A few hours a day adds up to a lot of writes for footage nobody watches.
Microsoft's support documentation describes Game Bar recording as something you start yourself. On Windows 11 and Windows 10, the shortcut is Windows key+Alt+R to start and stop a clip. Recordings save as MP4 files in a Captures folder under Videos. Nothing in that documentation says Game Bar records silently by default, so this habit is one you opt into.
Reasonable steps:
- Record only when you want the clip.
- Delete unwanted captures. This frees space but doesn't undo the writes already made.
- Lower the quality or bitrate if you capture often.
Habit 4: Chatty logs, with Docker as the poster child
Logs are useful until they aren't. The article warns about software that records irrelevant events, repeats the same error in a loop, or keeps recreating log files with no limit. It names Docker specifically.
Docker's own documentation backs this up. By default, Docker uses the json-file logging driver, which caches container logs as JSON. No log rotation is performed by default, so containers that produce a lot of output can use a significant amount of disk space and even exhaust it. Docker keeps that default for backward compatibility and for Kubernetes runtime scenarios.
The documented fix is to configure rotation. Docker's example sets the json-file driver's max-size to 10m and max-file to 3. Docker also suggests the local logging driver to prevent disk exhaustion. Third-party guides report that the local driver rotates and compresses by default, but check Docker's current docs for your version.
Some caveats:
- 10m and three files are example values, not universal best practice. Pick retention that suits your troubleshooting needs.
- Per-daemon changes generally apply to newly created containers. One guide notes existing containers keep their old config until recreated.
- Don't turn logging off wholesale. You'll lose the diagnostic history you need when something breaks.
This one matters most for developers running Docker Desktop with WSL 2 on Windows. Logs from busy containers can quietly pile up on your fast local drive.
The takeaway
| Habit | What's actually happening | Practical fix |
|---|---|---|
| Heavy torrenting | Out-of-order pieces can mean scattered writes | Download only what you need; check client settings |
| Repeated benchmarks | Tools write temporary test files | Fewer runs and smaller sizes; benchmark with purpose |
| Constant recording | A 20 Mbps stream is about 9GB per hour | Record on demand; lower bitrate |
| Unbounded logs | Chatty apps keep appending | Configure rotation (Docker max-size/max-file) |
The source is a personal advice column, not a measured study. It has no write telemetry, no before-and-after testing and no evidence tying the author's drive failure to any single habit. These are good hygiene tips, not a reason to fear normal PC use. For most people, the most useful step is to look up the real TBW rating for your drive and check how much you've written. SMART data from your drive's vendor tool will show that.