data loss on jffs2 filesystem on dataflash

[Artem B. Bityutskiy]

Andrew,

Andrew Victor wrote:
> I don't.  I set the wbuf_pagesize to the sector_size.
> (Which at that time was 1 or more eraseblocks.  And I think sector_size
> is/was the smallest unit of flash that JFFS2 would ever erase/write).
You used to think or still think :-) ?
eraseblock, which is of size = c->sector_size is the smallest JFFS2 
erase unit.
The smallest write unit is usually *smaller* then eraseblock and = 
c->wbuf_pagesize. Your DataFlash port has c->wbuf_pagesize = 
c->sector_size which is wasteful. This leads to much faster Flash wear. 
This makes unneeded loads to JFFS2. This should work, but not the best 
approach.

> Maybe there is some confusion here.  Dataflash has both 'pages' and
> 'blocks'.  With a 'page' being the smallest unit that can be
> erased/written.
Yes, but it is impossible to make JFFS2 eraseblock = DataFlash page 
size. Why? Because the page is too small. JFFS2's nodes cannot overlap 
eraseblock's borders. So, we cannot fit large 4K JFFS2 nodes to such 
small (1056 bytes) eraseblocks. Thus, the most logical approach is to 
make eraseblock size = DataFlash page size.

> 
> The MTD-device's erasesize is therefore set to the smallest unit - the
> Dataflash page size (528 or 1056, depending on device)
Well, may be this is right that *MTD* reports erasesize = DataFlash page 
size. But JFFS2 then must realize that it works on top of DataFlash and 
use blocks as erase units.

> Dataflash does not use Padding nodes.
I'm about JFFS2 - it pads wbuf. But well, it does not matter anyway. If 
your wbuf is 8K, you write there 100 byters then do sync, you wate (8K - 
100) bytes. It doen't matter whether you write padding or not. You waste 
the space, period. :-)

> Maybe it would be more optimal to set the wbuf_size to eraseblocksize? 
> I don't know.
Grrr. No! We don't understand each other at all :-)

> I do know that JFFS2-on-Dataflash was working fine when I committed the
> changes in February.
Now it doesn't :-) Sure, you don't have to fix it :-) We were just 
curious. I guess Peter should deal with this.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.