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

Re: $subject



Vipin Malik wrote:


>> The scary thing is that I don't think we can detect the case where the
>> block is mostly erased and there's only one or two words which might be
>> doing this, and they happened to return 0xffffffff when we read from
>> them.
>> Except by re-erasing all empty blocks when we mount :)
> 
> 
> Which would mean erasing the entire flash on a empty or mostly empty
> file system. Would it be faster to scan all free spaces, 3 or 4 times,
> and accept it as free and ok if it scanned free every time and
> erase it if even 1 bit is found to be not a "1".
> 
> 

And how do we determine how many times we have to test? If we test it twice is that good enough? Is 56 times enough? IMHO, it would be more straightforward to just go ahead and erase the sectors, but the time to do that could be an issue. If you read the specs, the MAX erase time for these parts is _very_ long. How about if we just start out with all the empty sectors as "pending" erase. In which case the filesystem can take care of erasing when it needs to instead of trying to erase half the chip at boot time.

Of course I also wonder what happens if the first read isn't all 1's, but I guess that it just looks like dirt.

> 
>> To avoid this, it's advisable to call the MTD power management suspend()
>> call before powering down the device in normal operation, and unless
>> it's
>> absolutely necessary, only continue with the power down if it/when
>> returns
>> 'OK'.
> 
> 
> Well, either it works fine after all (read > 5000) power down tests
> or not. If it works fine even in power down then why
> bother with the "special handling"?
> 

There are plenty of systems that have a wee little backup battery that could be enough to get us through erasing the last sector. The isssue would be that in these systems where we can be assured of a sane emergency poweroff we can take advantage of this to speed up the scan operation. Of course the 99.9% solution is going to fail when you most need it to work, so we need to be sure the solution is 100%.


-- 
Joe


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com