I have had a long and painful history using flash in general, and have
come to the conclusion that asynchronous removal of power is a very bad
thing. The following link shows one low level phenomenon called
"unstable bits". This seems to be getting worse the more bits that are
stuffed into a cell (pretty obvious) :-[
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
Some other studies suggest that very high density chips may exhibit
similar problems even when *_reading_* during a power fail!
My conclusions lean to removing power only when ALL accesses to flash
have completed.
HTH,
Dave.
On 03/27/2014 04:10 PM, John Syn wrote:
From: Brandon I <brandon.ir...@gmail.com <mailto:brandon.ir...@gmail.com>>
Reply-To: <beagleboard@googlegroups.com
<mailto:beagleboard@googlegroups.com>>
Date: Wednesday, March 26, 2014 at 6:46 PM
To: <beagleboard@googlegroups.com <mailto:beagleboard@googlegroups.com>>
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 <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
<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
<mailto: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
<mailto: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.
