On Wed, 01 Mar 2017 21:27:39 +0000, Dave Liquorice wrote:

> On Wed, 1 Mar 2017 09:01:58 -0800 (PST), raspibr@gmail.com wrote:
>
>> Is there any restriction about the amount of traffic data the SD can
>> handle? i'm afraid that my SD can be corrupted if a lot of information
>> arrive at the same time.
>
> Rate of data arriving I wouldn't expect to be a problem, thats what
> buffers and flow control are for.  B-)
>
> However if lots of data is being written erased rewritten etc you can
> "wear out" and SD card or memory stick. I had a Pi running as a time
> lapse camera, taking an 1920x1080 image every 30 seconds, adding a date
> time overlay, producing a timelapse every 6 hours (that took a couple of
> hours to render), rolling still image and time lapase store. This killed
> an 8GB micro SD card and an 8 GB memroy stick in around 6 weeks. An
> image every 30 seconds is 2,880 per day, double that for adding the
> overlay and add the 4 timelapse videos and rolling stores and aroound 8
> GB/day of writes would be happening...

Unless there are a *huge* number of hidden writes, that doesn't jibe with
the oft-quoted 100,000 write cycles expected before an SD card dies. I
think that those quoting 100,000 write cycles are assuming that the SD
card is built with SLC memory, so bear in mind that if 3 level MLC memory
chips are used instead the chip could die after as few as 1000 write
cycles. Two-level MLC memory falls somewhere between these two: 10,000
write cycles sticks in my mind, probably erroneously.

It was also mentioned several times that an SD card is thought to hold
data for up to 5 years between refreshes though several others thought
the usable *lifetime* of a card was 5 - 10 years. FWIW Sandisk guarantees
its cards for 5 or 10 years depending on the card type, but says nothing
about the of number write cycles the guarantee covers.

I've just had a scan for actual test figures, but found only one SD card
test project - and that hid its final results behind a password and/or
paywall. This project tested 2GB cards. Each test cycle copied 1MB chunks
of data from one half of the card to the other and back again, giving
effectively a whole-card read/write cycle. I assume that no SD cards have
deduplication built in: if they have, that test design would have given
bogus results. About the only test data they made available was that two
no-name cheapie SD cards failed after less than 100 cycles.

Other sites warned that using a journalling file system at least doubles
the write load on the card, so using ext2 or FAT32 filing systems should
give longer life than ext3 or ext4.

I should add that nobody seems to know how often wear levelling remaps a
card, how many write cycles per block this consumes or how the frequency
of wear levelling episodes varies with the fullness of the card.

About the only conclusion I can come to is that, as I've never had an SD
card fail in a camera, WinCE-based PNA or my Pi-1B (lightly used for
program development) then you should get good long SD card life from
doing office or development-type tasks with an RPi. However, If I was
using an RPi as a temporary store for large amounts of data, e.g. hung on
the back of a surveillance camera, then I'd either expect to replace the
SD card reasonably regularly or use it as a fairly static boot drive with
an ethernet-connected hard drive or a SATA-connected SSD added to hold
the mass data store.

Does this help anybody?


--
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

--- SoupGate-Win32 v1.05