On Thursday, October 4, 2018 at 7:40:39 AM UTC+2, Jan Panteltje wrote:
> 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

also use zram instead of a swap partition.
and put /var/log in a ram device (small, maybe 32MB) if you don't need
persistent logs.

Bye Jack

--- SoupGate-Win32 v1.05