In article ,
 Dennis Lee Bieber  writes:
> On Sun, 6 Jan 2019 10:23:19 -0000 (UTC), Markus Robert Kessler
>  declaimed the following:
>
>>- Is Kingston known as having severe quality problems?
>>
>  Kingston does not manufacture SD cards -- they buy up blank units from
> lowest bidder makers and put their label on them. I believe PNY is similar.

As someone else mentioned, there are loads of fakes around too,
although if you're going to the trouble to make a fake, you would
probably make a fake of a better quality product.

>  Don't recall if Transcend is a maker or relabeler, but have a small
> feeling that if they do relabeling, they may still be using higher quality
> cards.
>
>>- Is there anything I could do to try find out, what exactly went wrong?
>>
>
>  SanDisk (and Lexar to my knowledge) have their own silicon foundries,
> and would be a recommended choice. I did have a Kingston card for my first
> RPi -- and managed to kill it when running a benchmark suite (it did not
> survive having a section allocated to a swap file -- eventually had to run
> the benchmark with a TB USB drive for swap).
>
>  Note that SD cards are natively formatted in FAT -- a NON-JOURNALING
> file system. Linux EXT# (and NTFS) are journaling systems. Journaling
> systems are supposed to reduce the effects of corruption as they keep a
> journal of changes being made, and at later/idle periods finalize the
> changes. Power-failure in mid-update means either the update is completely
> lost (no change to original file), the journal is lost (so all updated data
> is lost, but no changes to original file), the journal and update were not
> lost, and can be used to finalize the actual file... But journals are "bad"
> for flash memory due to the amount of activity performed.
>
>  Also, cheaper memory cards may only maintain two "open allocation
> units" (one data file, one file allocation table), and a journaling system
> can easily be using three or more open AUs (data file, journal, and
> equivalent of FAT). On a two AU card, changing from AU to AU means flushing
> updates to an AU, locating a free AU in the card, ERASING that AU (SD cards
> can only write once to a sector without erasing), COPYING static parts of
> an old AU to the newly erased one, then appending new/modified data to the
> AU.

Journals and fsck are designed to handle failures of hard drives.
Failures of cheap flash (a.k.a. SD cards and USB thumb drives) are
different in nature, and neither a journal nor fsck are going to be
able to help. The typical catastropic failure is when the card fails
to save the logical to physical mapping table back to the flash.
This has the effect of shuffling a large number of blocks on the disk,
many of which were written ages ago. Some flash devices will go dead
at this point, others will just serve up wrong blocks all over the
place. That's not something journals nor fsck can recover. (I did let
fsck try once - it just got the drive into a hopeless mess.)

Enterprise flash products go to some length to avoid this catastrophic
failure mode.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

--- SoupGate-Win32 v1.05