Thanks Brandon for your experience. I do agree with that better to put whole disk read only.
But how do iPhone and Android survive? Esp for those Android phones? They are very prone to sudden power removal as well. How do routers handle this issue? they save the settings on different devices? I have a SQLite db around 1-2M and data will be written to them. Would like to have some easy and quick solution to make it absolutely stable. On Thu, Mar 27, 2014 at 9:46 AM, Brandon I <brandon.ir...@gmail.com> wrote: > Here's a good read: http://www.embeddedarm.com/about/resource.php?item=459 > > I had a loooooooong discussion about this with a colleague of mine after > we started seeing boards die. > > Basically you're eventually doomed unless you mount the whole disk as read > only since the wear leveling algorithms in the flash have no knowledge of > what a partition is and will eventually end up with > suppesed-to-be-read-only data mixed in with the writable partition erase > blocks. If you're writing to flash, it will eventually fail by unfortunate > design. > > It tooks his previous company 6 months of fighting to come to terms with > this in their last product. They had to write data, so eventually used usb > flash that the customer could easily replace when things eventually died. > They tried every flash card they could get their hands on, read only > partitions, etc and eventually had to give up. > > Use the SD card you say! Any micro SD card you can put in the slot is > absolutely not meant for continuous writing. The SD card spec has a very > specific use case in mind (video and images), and logging or using it as a > sparse write file system goes completely against the intended SD card > design specs. Industrial grade write-tolerant flash will cost you hundreds > of dollars more than something on Amazon. > > With our current product, I told my boss that I was worried about > corruption and that we would eventually go to read only once we debugged > the boards. Within two weeks of only log messages, all of our boards > started dyeing. The next day, all disks were mounted as read only and > issues are debugged with the in-memory log files. We haven't seen any > failures in 6 months now. > > The easy solution is trying to force the answer of "why are you writing > anything to persistent storage?" to be "there's no good reason since it > eventually bricks our product". If you want something that will last > forever, you will not write to standard flash media. If you can't, then > maybe use a usb flash drive (MUCH better life than a micro sd card) and > count the days until it corrupts or someone pulls the power at an > inopportune time. You could always use a battery backup to get rid of the > power off issue. :-\ > > This is all doom and gloom, but it's a consequence of inconsistent power, > buffers, and the destruction nature of quantum tunneling. > > -Brandon > > On Wednesday, March 26, 2014 2:45:57 PM UTC-7, Sungjin Chun wrote: > >> How about making system partition be mounted as read-only and data >> partition be mounted after booting and checking? In this case, only data >> partition has possibility of corruption. >> >> Sent from my iPad >> >> On Mar 26, 2014, at 9:53 PM, Yiling Cao <yilin...@gmail.com> wrote: >> >> Hi I have some my products deployed with am335x with Micron eMMC 2GB, but >> my products allow users to unplug power as they wish. >> >> My linux app very rarely writes to the eMMC. and my /etc/fstab specifies >> /var/log and /tmp to tempfs; fstab mount all partitions with "noatime" >> properties. >> >> But around 2 months of deployment, I found that around 1-2% am335x >> machines, have some sort of data corruption, resulting fail to boot up. >> >> Can anyone share some thoughts/ experience about how to resolve this >> issue? In real life product, whats the best practice? >> >> -- >> 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...@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. > -- 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.
