On a sunny day (Thu, 4 Oct 2018 01:18:18 +0000 (UTC)) it happened bob prohaska
 wrote in :

>Martin Gregorie  wrote:
>> On Wed, 03 Oct 2018 21:38:38 +0100, druck wrote:
>>> You need to use something that is designed to be primary computer
>>> storage, i.e. an SSD, as it's controller will not only be better at wear
>>> levelling, but also support all the health monitoring information.
>>>
>> I think this boils down to not using SD cards designed for capturing
>> streaming data, i.e. for use in a video recorder (type codes 10,
>> 30,60,90) for random access use, such as supporting a Linux filesystem.
>>
>I've just ordered a Samsung Evo + 128GB microSD card, basically as an
>experiment. It'll be close to twice the capacity I need, maybe that'll
>help the working life. It claims a uhs3 speed rating, but I'll believe
>that when the package arrives.
>
>The 16 GB card that failed actually lasted a rather long time; about
>six months of continual compiling, finally run up to over 90% capacity
>at the time it quit. In my environment that's probably an order of
>magnitude more writing than will happen in real use.
>
>Is there any chance re-partitioning the failed device might wring a little
>more life out of it? Badblocks reports all bad blocks, but I was able to
>write a small file on the DOS partition, so it's not totally stuffed.
>
>Thanks to everyone for reading and posting.
>
>bob prohaska

Just an idea, if you use extra partitions on such a big card,
then make sure you mount those with the 'noatime' option.
That significally reduces write cycles to the card:

https://www.howtoforge.com/reducing-disk-io-by-mounting-partitions-with-noatime

--- SoupGate-Win32 v1.05