5

I'm sure that they were not filesystem errors: reading it at the block level (pv /dev/sdb > /dev/null) gave a really low 1.4 MB/s and then at some point it stopped with "input/output" error, both from Linux (I/O error) and from Windows+Cygwin (event id 153 in Event Viewer, "disk" source). Trying to copy the files elsewhere, almost all of them could be read and some of them gave I/O error (part of the file could be saved, like pictures or videos cut in half)

It was used in an Android phone as secondary storage, Android reported that the card was failing and suggested to replace it. After that, I did the above tests on the PC with the built in card reader

Then just for a test before throwing it away, I formatted it on Windows (with exFAT). It took 6h (which gives also 1.4 MB/s) but run until the end. chkdsk d: showed 0 bad sectors

After that, the full card can be read at the block level at 18 MB/s, with no errors (tried on two different PCs). I filled it with files and also no errors when writing them or reading them afterwards

Was it fixed when formatting? or because of exFAT? Was it Android or the phone that wrongly changed some setting on the card?

Improve this question
6
  • 8
    "Fixed" is putting it a bit strongly. At best it has a metaphorical piece of duct tape holding it together. As gronostaj says it may have managed to remap or work around whatever was causing it to be slow but the process of writing and erasing flash memory is inherently destructive and each block only has so many times it can be rewritten. Yours has already shown that it is starting to die, so plan for its replacement. Flash memory is considered expendable.
    – Mokubai ♦
    yesterday
  • Sure, it was out of curiosity. Still, the read and write speed that it had before seems strange, as it was all over the card, even when reading the blocks that were OK
    – golimar
    yesterday
  • 2
    It could be that somewhere in the initial chain of blocks needed to find the filesystem was a bad block causing the lookup to be slow and dragging the controller down. You reformatting everything may have forced it to overwrite and remap that block thus returning the speed.
    – Mokubai ♦
    yesterday
  • 1
    @Mokubai : A couple unlucky slow blocks wouldn't explain plain block read with pv /dev/sdb being slow on average over the whole size of the device. Perhaps writing zeros (if that's what Windows exFAT formatting does) acted like a "trim" on an SSD, increasing spare sectors so it now has enough over-provisioning to reduce write-amplification, making writes cheaper. As well as having all in-use sectors mapped to non-slow sectors? IDK.
    – Peter Cordes
    10 hours ago
  • @PeterCordes we don't have any firm idea of exactly what kind of algorithms are used but I could imagine a case where a part of almost every read from a device being a "walk the tree" exercise of finding the first block of the device and going through a series of blocks that themselves act as a wear levelling system for the core metadata that the embedded controller uses. The controller will have absolutely minimal memory so may have to read that metadata on every transaction and as a result would be generally slow until it can be kicked out of reading a faulty block.
    – Mokubai ♦
    9 hours ago

1 Answer 1

Reset to default
13

Card's controller may have remapped bad sectors to spare ones.

That doesn't mean that this card is safe to use. Flash storage is notoriously fragile and your card already shows symptoms of problems. Don't store anything on it that you can't afford to lose.

Improve this answer
3
  • Is there a way to check that map of bad sectors or is it totally internal to the controller?
    – golimar
    yesterday
  • 10
    @golimar Maybe with proprietary tools designed for that particular controller. These are usually not available for general public and you don't know controller's model anyway. So theoretically it's possible, but practically it's not.
    – gronostaj
    yesterday
  • @golimar the mapping is internal, but there are tools (Victoria, Crystal Disk Info) that MIGHT be able to tell you how many sectors have been mapped
    – Josh Part
    9 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.