data loss on jffs2 filesystem on dataflash

[Jörn Engel]

On Tue, 20 September 2005 18:11:03 +0400, Artem B. Bityutskiy wrote:
> Jörn Engel wrote:
> >Still can't.  Block devices have the attribute that writing AAA... to
> >a block containing BBB... gives you one of three possible results in
> >case of power failure:
> >
> >1. BBB...BBB all written
> >2. AAA...AAA nothing written
> >3. AAA...BBB partially written.
> >
> >Flash doesn't have 3, but two more cases:
> >4. FFF...FFF erased, nothing written
> >5. AAA...FFF erased, partially written
> >
> >Plus the really obnoxious
> >6. FFF...FFF partially erased.  Looks fine but some bits may flip
> >   randomly, writes may not stick, etc.
> >
> >Now try finding a filesystem that is robust if 4-6 happens. ;)
> Don't underastand this. If you mean the atomicity, CRC may help here. 
> And no problems. Or may be you missed the the fact that we have 
> eraseblock size = writeblock size?

Image this block contains the used block bitmap of ext2.  All blocks
handled with this bitmap are free, so the complete block contains
zeroes.  Now we allocate a single block, writing a single one to the
bitmap.  When writing, a power failure happens right after the erase:

Before:
00000000000

After:
FFFFFFFFFF

Gee, every single block is used now.  Good thing this happened to the
block bitmap, so we only lost some space on the fs.  Somewhere else,
we'd have data corruption.

Any hard disk filesystem will suffer some kind of corruption in such a
case.  They heavily depend on the non-existance of 4-6.

> >>JFFS2 orients to "classical" flashes. They have no "write page with 
> >>built-in erase" operation.
> >What does this thing do?
> It erases individual page, then writes there. To put it differently, in 
> your terminology, eraseblock size = writeblock size.

Neat.

> P.S. I actually missed the mailing list, this should have gone to the 
> MTD ML. So let's move there please.

As always.  You fuck it up, I get to fix it. ;)

Jörn

-- 
Homo Sapiens is a goal, not a description.
-- unknown