On Wed, 23 Oct 2019 16:05:53 -0500, Knute Johnson
 declaimed the following:


>A 32GB card written to 1000 times is 32TB.  Write 1 million bytes per
>second to the card, 24/7/365 is 31.536 trillion bytes.  So at a million
>bytes per second the card will last a year.  At only a thousand bytes
>per second the card will last a thousand years.  Unless you are doing
>something really strange you aren't going to write to it that much.
>
 That presumes you are writing to all parts of the card. It also doesn't
account for the effects of using a journaling filesystem.

 Take a card where only part is available for updating files, and in
which the journal updates too, and the number of writes increases rapidly.

 Also, the way SD cards work is NOT simple byte counting -- opening a
file to add just one byte requires the card to allocate and erase a
complete allocation unit, then copy the file to the new unit, write the new
data, and put the old unit into the free list for erasure. The erase sets
all bits to "1" -- writing can only convert a "1" bit to a "0" bit.

 Streaming a 32GB file to a blank card, erasing it, and streaming
another 32GB is light usage. Instead, try creating 320 million 100KB files,
then start randomly deleting 8 million of them, then create 8 million more
files, repeat, randomly deleting files before creating new ones. Each of
these delete/creates will hit the journal first, before the file itself is
modified.

journal    filesystem
deleting file X
     free file space used by X
deletion committed (flag journal entry that this action has completed)

That's three write operations minimum just to delete one file. Creation is
more complex.

 On some cards, the allocation unit could be measured in multiple
megabytes. Cheaper cards, optimized for FAT (a non-journaling) filesystem
may only have the ability to "hold open" two allocation units -- one of
which is like the FAT itself. Anything that jumps from one file to another
could result in closing the other allocation unit and opening another --
and as mentioned, if the opening is to add data, the cards need to obtain a
spare unit, erase it, and copy unaffected sectors to the new unit before
writing the modification. An open unit can continue to have modifications
written to the "erased" portion, but once the unit is close the "knowledge"
of what is used vs what is writable is lost and the next time modifications
are made to the unit requires a new allocate/erase/copy cycle. Better cards
can sustain maybe 4 to 6 open units -- so multiple files can be open in
different units without triggering allocate/erase cycles.

 Class 10 cards are rated for single file streaming to freshly
formatted/erased media (eg: video). Class 2/4/6 were rated for multiple
small files and fragmentation (eg: photos with some deleted in camera).
Hence, cheaper class 10 cards with 2 allocation units may perform poorly
relative to a class 4 card with 6 allocation units when used for computer
filesystems.

 Checking my archives gave me
https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey?a
ction=show&redirect=WorkingGroups%2FKernel%2FProjects%2FFlashCardSurvey
which is now a dead link.

Still alive, but not as detailed as the above used to be...
https://lwn.net/Articles/428584/

"""
Restrictions on open segments

One major difference between the various manufacturers is how many segments
they can write to at any given time. Starting to write a segment requires
another physical segment, or two in case of a data logging algorithm, to be
reserved, and requires some RAM on the embedded microcontroller to maintain
the segment. Writing [SSD thrashing] to a new segment will cause garbage
collection on a previously open segment. That can lead to thrashing as the
drive must repeatedly switch open segments; see the animation behind the
diagram to the right for a visualization of how that works.

On many of the better drives, five or more segments can be open
simultaneously, which is good enough for most use cases, but some brands
can only have one or two segments open at a time, which causes them to
constantly go through garbage collection when used with most of the common
filesystems other than FAT32.
"""

 Only tangentially related: http://wiki.laptop.org/go/NAND_Testing

 And http://haydenjames.io/increase-performance-lifespan-ssds-sd-cards/
implies that every file access can trigger changes on an allocation block
level if the filesystem/OS is maintaining the time of last access for each
file.


--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05