8

I'm sure that they were not file system 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 an 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 6 hours (which gives also 1.4 MB/s), but it ran 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?

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
golimar
  • 1,522
  • 1
  • 17
  • 35
  • 10
    "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 Apr 06 '22 at 06:56
  • 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 Apr 06 '22 at 07:27
  • 3
    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 Apr 06 '22 at 07:47
  • 2
    @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 Apr 06 '22 at 21:57
  • @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 Apr 06 '22 at 22:53
  • @Mokubai: Oh, you meant chain of blocks needed to find/read the flash remapping table by the flash controller internally, if it doesn't have enough DRAM to cache that. Which it needs to find the logical blocks of storage it exposes. Not to find data in the exFAT filesystem that sits on top of that. Yeah could be. If Windows did some special kind of erase command before formatting, it could have let the SD card discard the previous flash remapping data structure. – Peter Cordes Apr 06 '22 at 23:12

1 Answers1

20

The 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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
gronostaj
  • 55,965
  • 20
  • 120
  • 179
  • Is there a way to check that map of bad sectors or is it totally internal to the controller? – golimar Apr 06 '22 at 07:25
  • 11
    @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 Apr 06 '22 at 07:58
  • 1
    @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 Apr 06 '22 at 22:43