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

RE: $subject



>> 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,

You are correct of course. This is a trade off. The more times
you read, statistically the higher chance that you will catch
a flipped bit. Of course, even reading many times is a decreasing
value function, as at one cross over point, the time to read n times
multiplied by the probability of missing a "bad" sector will be
greater than the sector erase time.


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

As the code currently stands, this will cause the f/s to fail as
it will think that there is no free space between the head and the
tail.
So we have to erase the sectors ourselves immediately after the
scan before passing control back to vfs mount, meaning that
these sector erases cannot continue in the background.

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

Yup. This is the case that works ok.

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

Plus, more important, jffs on mtd is not a "generic" solution any more.
The end user has to be aware of this limitation. Additionally
most systems that I have worked on (or designed), this "advanced
power fail warning" is only a few 10's of ms to a few hundred ms,
which is not long enough for a sector erase even during the 
early stages of the flash chip where the sector erase times are
best case.

I think that a more generic solution that works regardless of 
power fail warning is more robust, even if that means long mount
times on sparse or empty file systems.
 
Maybe it can be an option in make config.
"CONFIG_JFFS_FAST_MOUNT"- y/n (with num re-reads user defined) or 
"CONFIG_JFFS_HIGH_CONFIDENCE_MOUNT"- y/n (which would erase all
empty sectors). This way the user can choose depending on
their application.

:)

Vipin


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