IO errors on SSD drive. Keep as a spare or discard?

If you people get a dodgy SSD do you just chuck it out immediately? I already replaced it and now the errors have stopped.

I didn’t keep the journal logs but it was IO errors on /dev/sda during boot. It’s a Sandisk 128gb, it’s nothing to write home about.

SMART reports no errors and is it’s usual helpful self.

1 Like

Good question - am wondering about this was well. Just this afternoon my laptop booted very slowly. In TTY1 saw the text on the Bootscreen mentioned that unused blocks were discarded. First thought was the SSD is failing, but the SMART test gives the SSD the “nothing to see here".

In think I’m going to do some more tests but may well decide to simply replace the SSD.

1 Like

This shouldn’t mean that there is something wrong with your disk.
It indicates that you have continuous trim enabled for your device, most probably as a mount option in /etc/fstab.

2 Likes

This wiki will give more information about the trim options. But if I am not mistaking the weekly schedule will be set automagically when installing EOS.

1 Like

personally if I needed something to play with (test physical installs) i would keep it for that. I would not keep any important or needed information on it. If you have no need for it then you can just finish the job like I do when I’m done with a disk. Tear its soul apart :wink:

1 Like

If SMART reports no errors and the disk is healthy, the IO errors may also be indication of filesystem problems.

I’ve had no forced shutdowns. The machine started taking ages to boot up so I ran Journalctl and one of the latest entries was the IO errors. I wonder what could cause file system errors.

have you run a disk check on it? all kinds of things can cause file system issues.

1 Like

Thank you, @cactux - will look into this.

1 Like

You could check your mount options with:

findmnt --real

It could also be that you have the fstrim.service enabled for periodic trim. Check:

systemctl status fstrim.timer

Looked into this.

fstab:

UUID=<long number> / ext4 noatime 0 1

The log entries are:

Finished Discardunused blocks on filesystems from /etc/fstab.
Stopped Discard unused filesystem blocks once a week.

findmnt --real, says:

TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p2 ext4 rw,noatime

systemctl status fstrim.timer says:

fstrim.timer - Discard unused filesystem blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer;enabled; preset: disabled)
Active:active (waiting)since Wed 2025-11-26 08:11:46 CET; 4min 24s ago
Invocation: 115c0d1c206045609ce1969e5e4b818d
Trigger: Mon 2025-12-01 00:50:39 CET; 4 days left
Triggers: ● fstrim.service
Docs: man:fstrim

So, it’s clearly a weekly run job. Don’t remember setting this up myself, though.

It was not my intention to hijack the topic from OP, but thanks for your help!

1 Like

Thank you.

Yes, I also believe EOS sets this up as a weekly job during install, as it’s active on my system and I do not remember setting this up myself (which, perhaps, is not saying much :wink:).

2 Likes

I shall use this as a learning experience as I’ve never used fsck before. Even if I bin the drive at least I’ve tried something new.

Hopefully an external usb enclosure will suffice as I can’t fit a second internal drive in any of my machines.

1 Like

If it were me I would run a secure erase method. On ssd you cannot zero out the drive like old HD’s. You can accomplish this using the blkdiscard command to overwite the entire drive. Then you would need to re-partition it and format. This is the fastest and most recommended way.

Another alternative would be to use hdparm if the drive supports secure erase command.

You could aslo use dd command to overwrite the drive which is effective but very slow.

You could also use wipefs if you only want to remove the partition table and file system signatures so the OS can’t recognize them, but it does not erase the entire drive.

True low-level formatting is not applicable to modern SSDs. Commands like blkdiscard or the secure erase command are the correct way to securely erase data.

Commands like hdparm --security-erase or blkdiscard can help reset the drive to a clean state, which can sometimes restore its performance.

True low-level formatting is not applicable to modern SSDs. Commands like blkdiscard or the secure erase command are the correct way to securely erase data.

A lot of modern motherboard UEFI have the ability to secure erase the drives also and i have used it on my modern Western Digital Black drives. I’m not sure what method it’s using to accomplish this.

Also be aware that you must know exactly what you are doing when using these methods or you can easily destroy data or erase discs unintended.

Are you suggesting I zero the drive to test writing to all of the nand?

I ran fsck and it didn’t find any errors. I reran the s.m.a.r.t test in gnome-disk-utility and no errors reported.

If I can’t rely on it as a system drive I don’t really have any use for it. I haven’t chucked it out yet though. I think my lack of knowledge might make it more unreliable tbh.

I’m not suggesting you do anything. I’m merely pointing out what i would use to clean the drive and make it like new again if it doesn’t have any actual hardware issue.

1 Like

Sorry I didn’t mean are you suggesting that I personally do this. I meant is the reason to do this to test the drive or restructure it. I get what you’re saying now.

1 Like

Depends, if it constantly throws errors it goes into the trash.

It threw some errors and you don’t trust it anymore with important data, but works fine otherwise? Free cache drive! Swap, cache (pacman, ~/.cache, …) - everything that doesn’t hurt if it goes away in an instant.

1 Like