JFFS3 & performance

[Jörn Engel]

On Wed, 12 January 2005 18:37:00 +0100, Thomas Gleixner wrote:
> On Wed, 2005-01-12 at 17:59 +0100, Jörn Engel wrote:
> > Ok, you completely ignore the central issue.  Looks like I was unclear
> > about it.
> > 
> > What happens, if crucial data in flash gets corrupted and is unusable?
> > Say, /sbin/init.
> 
> I totaly agree that it must be sure that stuff does not get corrupted. 
> 
> We use MTD for embedded systems since long and I'm well aware that data
> might be corrupted. So most of the systems have a ro partition for
> crucial stuff which only is mounted rw for updates under safe
> conditions. The application data is living on a different partition.
> 
> For critical systems we have a backup emergency root, which we can
> activate when a update smashes the normal rootfs. There are other
> userspace possibilities to take care of backups and fallback.
> 
> So I don't see the point of an enforced mirror in MTD which will bring
> more complexity than it is worth, but I might have missed some points.

So my last mail in this thread for NAND analysis.  It basically states
that data corruption is nothing we have to worry about a lot.  Maybe a
little, depending on your preferred reliability.

Same goes for NOR, DRAM and hard drives, so I feel pretty safe.

Now, if some El-Cheapo manufacturer would come along and create an
ultra-cheap and ultra-unreliable new type of flash, we might need to
reconsider something like the mirroring, but only for this particular
type of flash.  Let's hope this never happens.

So again, I don't care too much, whether jffs2 can scavenge some bytes
of data from a rotten block, simply because this never happens (for
all practical purposes).  If it's simple enough, sure, go ahead.  If
it's complicated and ugly, please don't.

Jörn

-- 
It's just what we asked for, but not what we want!
-- anonymous