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

RE: $subject

>Heh. I actually found this in testing JFFS2 a day or so ago, too. I was 
>triggering the 'ofs 0x%08x has already been seen.' complaint in 
>jffs2_scan_eraseblock, because the same thing was happening - first reading
0xffffffff then
>jffs2_scan_empty was reading something different
>and deciding that the length of empty flash was zero. 

From the mode of failure (erase never completing because of 
async pwr down), I would expect to encounter this problem only
during power down testing. How did you encounter this? Are you
doing power down testing too?

>In jffs1 you should also be able to erase it immediately, but it's just 
>a little more difficult to determine that's the case. The initial scan 
>will see it as 'dirt' in the middle of the free area, and that's why 
>everything gets confused.

In my "patch" to fix for non aligned offsets I only accept free spaces
that are at least 1 erase sector long. But I guess that any trailing
space into the next sector may have this problem.

>> I don't have a fix in place yet, but will try out something soon.
>> I guess, detect something like this and just mark the entire
>> erase sector as "dirty". Don't bother to read the data contents
>> a double word at a time to figure out what's in there.
>> The gc thread would then just erase the sector as part of the 
>> normal gc process. Once erased, the sector is then as good as new.

>Yes, sounds reasonable, except I think you ought to do the erase 
>immediately, and you need to make sure it doesn't confuse the scan code 
>into thinking the head or tail of the log is at one end of the offending

>block when it shouldn't be. If we account lots of space which is
>free as dirty space just because it's between the offending node and the

>real head or tail of the log, we may run out of free space totally and 
>kill the filesystem.

David, is it correct if I assume, that we must correctly identify the
head and tail of the log, during mount, which corresponds to the
head and tail of the fs log that the system had *last time*, i.e.
before power failed?

>It may require turning the scan into a two-stage process - first
>the jffs_fm list of nodes, and then in the second pass going through it
>looking for the largest expanse of space which is either clean or
>erasable, doing the necessary erases and setting up the rest of the data
>structures to make that the free area between the head and the tail
>of the log.

..but from this comment the above (what I wrote) does not seem to be
true. It seems that the system will behave correctly regardless
of where the head and tail end up on every new mount, as long as
there is enough free space between the two?

>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
>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".

>To avoid this, it's advisable to call the MTD power management suspend()
>call before powering down the device in normal operation, and unless
>absolutely necessary, only continue with the power down if it/when

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"?

>Obviously we should deal as well as possible with the case where that
>hasn't happened, so the testing is very useful.

My previous power down test experience has shown that any weakness
in the system is usually found within a few hundred cycles.
If the system passes about 1500 cycles, it will run to 5000+ cycles
without any problem. And if you do the math- for "regular" systems
which are not that flash write happy (as my test is) 5000+ cycles
of reliable operation would map to a miniscule failure rate in the field
even if there is still a problem that was not detected in the tests.

At least I would be happy with it. Considering so many embedded
systems are shipped with nary a power down test, we would be way
ahead in the game :)

David, any day of the week you'r not working ;)


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