Re: Killing JFFS under 2.2

[Sébastien Côté <scote1@xxxxxxx.com>]

David Woodhouse wrote:
> 
> scote1@xxxxxxx.com said:
> >  I'm not sure how this was implemented but IMHO you shouldn't start
> > writing in the middle of a sector.  An inode can begin in the middle
> > of a sector if the beginning of that sector has already been used.
> 
> The beginning of the sector _has_ already been used.
> 
> The image which was left on the flash when I powered down looks like this:
> 
> +---------+-------+-----------+-------+---------+-------------+
> |   0xff  | 0x00  |    DATA   | 0xff  |  DATA   |    0xff     |
> +---------+-------+-----------+-------+---------+-------------+
> 0      0x40000    |        0x2cde8c   |     0x2f5e58       0xf00000
>                0x417c4             0x2cfec8
> 
> The sector in question runs from 0x2c0000 to 0x2e0000, and it's only the
> space from 0x2cde8c to 0x2cfec8 which is empty. The rest holds JFFS nodes
> which appear to be valid.
> 
> For some reason, though, jffs_scan_flash() ends up with fmc->head->offset
> being 0x2cfec8, which means that jffs_erasable_size() always fails.

This is even worse, no ?  I can't see why the middle of a sector would
be empty. fmc->head->offset if probably set to 0x2cfec8 since it sees no
data in front of it when it scans (I would have to check how this is
set). 

> scote1@xxxxxxx.com said:
> >  Did you change the fmc->sectorsize to match the actual size of the
> > erase sectors on your flash ?
> 
> I believe that change is already in the CVS tree, yes. But even if it
> wasn't, that wouldn't explain the existence of a node at 0x2cfec8 - that's
> not aligned on 64KB either.

Yeah, you're right....

-- 
Sébastien Côté