From: Brandon I <[email protected]> Reply-To: <[email protected]> Date: Wednesday, March 26, 2014 at 6:46 PM To: <[email protected]> Subject: Re: [beagleboard] eMMC data corruption due to power removal?
> 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. What you say is mostly correct. However, you can use supercaps based power supply which will enable you to store data stored in RAM to Non-Volatile storage such as SDCard or eMMC when a power fail is detected. Also, when Linux goes through an orderly shutdown, no corruption occurs. This way, you only write to flash during a power failure so you won¹t see any flash failures. The supercaps don¹t have a limited number of charge cycles which is common in Lithium Iron batteries so these systems should be good for 10 years or more. Plan for about 90 Seconds to write data to flash and Linux shutdown. Regards, John > > -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 <[email protected] <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 [email protected] <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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
