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 <javascript:>> > 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 <javascript:>. > 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.
