[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: intrep.c update to handle gaps in the middle of the log.



Simon Munton wrote:
> 
> This update seems to bring about another problem.
> 
> My flash image (size = 0x7e0000) looks like this:
>         0x000000 - 0x2c8cff:    valid nodes
>         0x2c8d00 - 0x75ffff:    all 0xff
>         0x760000 - 0x76049f:    all zero
>         0x7604a0 - 0x7dffff:    valid nodes
> 
> With this update it results in the whole 0xff area being treated as dirty.
> If I try and copy a file on to it, it reports that the file system is full.
> 
> I think you need to restrict the amount of space treated as dirty to be in a
> single erase sector. Also, if the end of the area is at an erase sector
> boundary, don't treat as dirty at all.
> Do you need to check if nodes have already been found? Won't you also get
> the problem at the very start of the flash? (your original failure happened
> when you powered off mid update - but the sector being updated could easily
> have been the very first one).

Our original problem was a "hole" between two valid nodes (we forgot to
check if the data that followed was valid in the patch) but you're
right, it could happen to the first sector.  Maybe we should only check
if a free space ends in the middle of a sector.  In that case, treat the
beginning of that sector as dirty.  Would that do the trick?

If we have :

>         0x000000 - 0x2b0000:    valid nodes
>         0x2b0000 - 0x2b7000:    all 0xff	The error occured here
>         0x2b7000 - 0x2c0000:    all zero      We set this space as dirty
>	  0x2c0000 - 0x2c8cff:    valid nodes
>         0x2c8d00 - 0x75ffff:    all 0xff
>         0x760000 - 0x76049f:    all zero
>         0x7604a0 - 0x7dffff:    valid nodes

(Suppose all dirty space and valid nodes starts on the beginning of a
sector, I didn't want to do the math)

Would the filesystem be mounted correctly or do we _have_ to set the
first free space (where the error occured) as dirty too ? 

-- 
Sébastien Côté