Re: JFFS3 & performance

Jörn Engel
2005-01-12T18:17:37Z

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