USB SSD randomly unmounting

I had an 500 GB Samsung EVO 850, connected to an rPi4 via a USB to SATA adapter, shared via Samba. It had worked this way for years.

A couple of weeks ago it went offline, and wouldn't remount. I switched off power and restarted, and it worked OK, for a bit, but it dismounted again, after about 24 hours. I changed the USB/SATA cable, but the problem persisted.

As this was my main server, which I needed to work, I bought a new SSD, and copied everything across. Everything all now works fine.

The thing is, I can't now see anything wrong with the problematic SSD. fsck says it is OK. Smartctl says it is OK, but can't run a long test (the long test always says "Aborted by host" 90% remaining). The SSD now stays mounted on another machine, still USB.

My guess is there was something like a bad block, which caused the SSD to dismount when it was accessed. Now that the SSD isn't being used heavily, the problem just doesn't show up, it stays mounted. Previously, It was being used for a security camera, so a fair bit of writing.

I know I should just bin the drive, but I'm curious, is there a better way of testing it, finding a fault?

That isn't a normal respose in Linux. For ext file systems the behaviour is:

errors={continue|remount-ro|panic} Define the behavior when an error is encountered. (Either ig- nore errors and just mark the filesystem erroneous and continue, or remount the filesystem read-only, or panic and halt the sys- tem.) The default is set in the filesystem superblock, and can be changed using tune2fs(8). (from EXT4(5))

For FAT filesystems it's:

errors={panic|continue|remount-ro} Specify FAT behavior on critical errors: panic, continue without doing anything, or remount the partition in read-only mode (de- fault behavior). (from MOUNT(8))

So between continuing and halting the system, the only other option should be remounting read-only, not unmounting the filesystem.

Perhaps there was some service unmounting it automatically because it thought the drive had been disconnected? Anyway it shouldn't be able to happen due to read/write errors.

Thx, I was just guessing. I posted a bit of sys log in response to Jan. It didn't make much sense to me, but maybe it will to someone else.

compare its SMART with the good one...

That looks sick. uas is USB Attached SCSI, so the above means the Linux kernel tried to issue a UAS command and for some reason it failed.

Eventually the errors stack up and Linux tries to do things like resetting the device in the hope it'll fix it, but they don't.

The first thing I'd do is try updating the firmware:

If you're been doing a lot of security camera writes it's possible it's worn out the SSD.

Theo

Badblocks

Don't SSD's reserve some spare "blocks" (whatever they are called) that get used to replace faulty ones. Won't smartctl tell you if that has happenned?

smartctl was designed for hard discs which are far simpler, only having sectors on spinning rust, it may or may not show the relocated sector count for SSDs, but this might not be the whole story.

An SSD may have multiple types of flash, with the main bulk being slower and cheaper 2, 3 or 4 bits per cell, but also a cache of faster expensive single bit per cell flash. There is also the storage which contains the crucial mapping of logical addresses to flash blocks.

A failure of a certain percentage of the main flash can normally be accommodated by over provisioning, but a failure of the cache or mapping store may cause the SSD to go in to read only mode.

Sometimes a complete reformat of flash memory devices can appear to temporarily clear problems, but the wear life doesn't magically come back, and would you want to trust it again?

---druck

I upgraded the firmware with Samsung Magician. Samsung Magician does not have diagnostics for the EVO 850. All in all, it is pretty crap, for anything apart from the firmware update.

SMART says 83% healthy, meaning the Wear Levelling Count. The drive has

The warranty is also 5 years. Coincidentally, this problem seems to have occurred at almost exactly 5 years Power-on Hours, but I guess the warranty was ownership time, not power on time.

One suggestion to check health was to clone the drive, and look for errors, but I'd already used rsync to copy the entire drive.

It all seems like more hard work than it should be. I'll see if I can find a simple use for it where I care even less about reliability. Some kind of cache or sync drive. Maybe I'll see if I can run 3 drives off the same rpi4 :-).

FWIW, I've seen behaviour like that too. In the case I saw, it was a USB stick which would dismount every few minutes. And the fix, like yours, was to replace a presumably dodgy PSU with an offical RPi one.

John

I too, have had problems with power and USB drives, one of my SATA adapters is powered, not the one for the drive that failed. I think the drive also failed in the powered adapter too, but I wasn't methodical enough to be sure. I was getting uptight about losing some of my essential services.

In this instance, I suspect it isn't the problem, given it has worked for years, and I have a 20 amp USB power supply, no under voltage entries in the log.

Anyway, I umed and ahed about it. I couldn't decide if the SSD is crap or not. The new, working, SSD replacement, is lower power.

So earlier today, I ordered a USB/SATA dual docking station. I'm going to put the old drive in there and just use it for CCTV, at a higher refresh rate than before, because I no longer care about it.

We'll see what happens :-).