systemdBoot is supposed to be true, not a typo. But yeah, I don’t use plasma much so I don’t really know how to solve the issue… Sorry for that!

Always have a backup.

Badblocks shouldn’t output anything when run on an ssd. It’s not really useful for its intended purpose there because ssds have hundreds to thousands of bad blocks to start with (depending on how you define “blocks”) and reprovision messed up sections all the time to cover up the fact that they’re screwing up constantly from the bus.

It’s also true of rotational hard drives nowadays, not that they’re fundamentally based on using a medium that’s incredibly prone to “failure” but that they don’t expose the actual addresses on the medium to the controller.

The old way, what the bad blocks tool is intended to address, is like if there were a big warehouse and when you wanted something you asked for the thing in rack 6F, shelf D8. The disk goes and gets it for you and if it’s the right thing then you’re golden and if it’s wrong you got a problem.

Badblocks -n grabs the thing on 6F,D8, sets it aside and asks the disk to put something else in there, then asks for it back. If it succeeds then wonderful! “Block” 6FD8 is good and it puts the thing that was originally there back and moves on to the next one ad infinitum.

Of course, new rotational disks and all available ssds don’t actually work like that. You hand the disk an object and say “put this in 6FD8” and the device says “you got it” and then promptly opens the package you handed over and puts its contents wherever it wants.

When you ask for 6FD8 back the device grabs all the stuff that’s supposed to be there, puts it all back together and hands it to you. The disk itself might have all kinds of messed up things going on internally and you only see it when the data you put in doesn’t come out the same.

Part of what makes the secure erase functionality work on ssds is that very insane obfuscation. When there’s no actual physical structure to the way data is stored, no “raw” read of the ccd chips can make heads or tails of it. The disk can be easily and quickly “wiped” just by asking the disk itself to kindly forget its own key used to locate information requested and viola! Secure erase!

Of course, none of that matters because we’re not using badblocks to figure out if there are bad blocks, we’re using it to force the ssd to rewrite its ccds so they respond to requests faster.

The behavior we care about is writing something to the “block” then erasing it and rewriting the original data into it. Badblocks -n should do that.

There are times when it might not though, the ssd may hand you porno.mov out of “6FD8”, write random data to somewhere in the ccd chip that it writes down is supposed to be 6FD8, read it back to badblocks, then when badblocks says “alright, that one passed, lets put porno.mov back there” the ssd says “wait a second, I have a string of bits that matches this!” And just update its internal ledger that 6FD8 is now what it was before that silly random data kerfuffle, never actually rewriting anything.

It saved a write cycle on those cells after all! It did you a favor!

So sometimes badblocks -n doesn’t work in this application. Spinrite is the “correct” tool, but for some applications it doesn’t work either (non x86 systems) so I use dd in that case to just slam the disk full of something so it can’t reprovision and save any write cycles and writes every possible cell with something. That destroys data, of course.