I assumed that everything is the same (flash technology, memory block size, memory block life, etc) between the 4Gb and 16Gb card, except the number of memory blocks. The more free memory blocks there are, the more blocks the wear leveler can touch before cycling through all of them.
I assumed you had 2Gb of free space on your old card, so, scaling the time by the extra memory blocks available: 3months * 14Gb/2Gb = 21 months. Flash is crazy dense and cheap to make, but the eventual failure is the price you pay for, literally, shooting electrons through glass. :) On Fri, Jun 13, 2014 at 8:37 AM, Fred Basset <fredbasset1...@gmail.com> wrote: > Brandon, > > I'm curious as to how you calculated a lifetime of 2 yrs for the 16Gb card > with 2Gb free? > > > On Thu, Jun 12, 2014 at 11:55 AM, Brandon I <brandon.ir...@gmail.com> > wrote: > >> With a 16Gb card, you'll most likely get about 2 years use before the >> card fails, assuming you had 2gb free on your failing cards card, the 16Gb >> card has the same number of writes until failure for the memory blocks, and >> the same disk activity. >> >> This assumes that you're have a perfect power supply that never shuts off >> during a write (which will damage the memory cells) or unflushed operation >> (which can corrupt the filesystem). >> >> If you're writing to flash media, it will eventually fail. :-\ Ideally, >> you would have your os disk read only (read only partition doesn't >> necessarily work due to sd card wear leveling controller not being aware of >> partitions), and log files logged elsewhere where your software could >> gracefully handle the eventual failure of the log file flash disk. Have >> this log file disk easily accessible for customers to change. >> >> You could not flush your log file writes until some sort of failure or >> buffer size, so that you're not writing whole erase blocks for a sentence >> worth of log message. And, of course, turn off all the access time >> capabilities with your mount options (noatime, nodiratime). >> >> The only solution is to reduce the number of writes each memory block is >> seeing in a day, and be aware that eventual failure can't be avoided if >> writing anything. >> >> On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote: >> >>> On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy <tala...@gmail.com> >>> wrote: >>> > >>> > Hi everyone, >>> > >>> > I've been using the BeagleBone Black for a while now. I got my apps >>> running >>> > just fine for like 2-3 months straight, not a single problem. >>> > >>> > OS : Debian Wheezy installed on Samsung 4GB µSD card. >>> > Cross compilation platform : ELDK (armv7-hf) >>> > >>> > I've tested my apps on different brands of SD Cards (Kingston, >>> samsung, >>> > sandisk ...) and have killed several Kingston cards in a matter of >>> days. By >>> > killing, I mean the BeagleBone wasn't booting on them anymore and they >>> were >>> > no longer mounted when plugged via a USB-Card-reader. I had this kind >>> of >>> > dmesg output (the [...] here means a lot of the same 7 lines in a >>> loop): >>> > >>> > [626903.528266] sd 11:0:0:0: [sdd] Device not ready >>> > [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK >>> > driverbyte=DRIVER_SENSE >>> > [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] >>> > [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present >>> > [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 >>> 00 08 >>> > 00 >>> > [626903.528287] end_request: I/O error, dev sdd, sector 0 >>> > [626903.528290] Buffer I/O error on device sdd, logical block 0 >>> > [626903.530266] sd 11:0:0:0: [sdd] Device not ready >>> > [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK >>> > driverbyte=DRIVER_SENSE >>> > [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] >>> > [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present >>> > [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 >>> 00 08 >>> > 00 >>> > [626903.530287] end_request: I/O error, dev sdd, sector 0 >>> > [626903.530290] Buffer I/O error on device sdd, logical block 0 >>> > [626903.532391] sd 11:0:0:0: [sdd] Device not ready >>> > [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK >>> > driverbyte=DRIVER_SENSE >>> > [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] >>> > [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present >>> > [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 >>> 00 08 >>> > 00 >>> > [626903.532412] end_request: I/O error, dev sdd, sector 8 >>> > [...] >>> > [626903.812724] sd 11:0:0:0: [sdd] Device not ready >>> > [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK >>> > driverbyte=DRIVER_SENSE >>> > [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] >>> > [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present >>> > [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 >>> 00 08 >>> > 00 >>> > [626903.812740] end_request: I/O error, dev sdd, sector 0 >>> > [626903.814725] sd 11:0:0:0: [sdd] Device not ready >>> > [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK >>> > driverbyte=DRIVER_SENSE >>> > [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] >>> > [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present >>> > [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 >>> 00 08 >>> > 00 >>> > [626903.814747] end_request: I/O error, dev sdd, sector 0 >>> > [626903.820536] sdd: detected capacity change from 3947888640 to 0 >>> > >>> > >>> > That's why I chose to use Samsung sd cards instead. Everything was >>> fine for >>> > 2-3 whole months, but now I had one of my systems getting the exact >>> same >>> > symptoms as when using the Kingston cards. >>> > >>> > Did anyone experience this kind of problem using his beagle bone so >>> far ? >>> > Does anyone have an idea of something that could damage the SD card so >>> much >>> > which is or isn't directly related to the use of a beagle bone black >>> (Heat, >>> > compulsive logging, ...) ? >>> > Can anyone suggest a brand that has solid and enduring SD Cards for an >>> app >>> > that is logging quite regularly ? >>> >>> I use SanDisk Ultra's 16GB's on my bbw & bbb's on my gcc testing farm. >>> Those microSD's have been running fine for almost a year now, under >>> 100% load for 24/7 bulding/testing gcc stable branches. (lots of file >>> deletions/creations). Previously to that i had been running SanDisk >>> Ultra's 8GB variants, but starting with gcc-4_8-branch i began to run >>> out of build space. >>> >>> http://rcn-ee.homeip.net:81/dl/gcc/archive/20140610-11:24- >>> gitb28747e-gcc-4_9-branch-am335x-boneblack-512mb-1/ >>> >>> Regards, >>> >>> -- >>> Robert Nelson >>> http://www.rcn-ee.com/ >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/r69muHCERqg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
