[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Killing JFFS under 2.2
Finn Hakansson wrote:
> Hmmm... I haven't encountered this problem before.
It's because I schedule() while waiting for the erase to complete, rather
> I too prefer the mutex solution but I think the patch should stay in
> because it makes the scanning of the filesystem more stable. If, for
> whatever reason we can't think of right now, a hole appears in the
> middle of the data, the filesystem shouldn't be prevented from loading
I agree with both of you. We should prevent it from happening, but also
deal with the situation just in case it does.
My preferred method of preventing it is to perform all writes sequentially
from a single kernel thread - and because that will take a while, I
thought it appropriate to start with the simple hack which you observed.
> When an embedded system relies on JFFS to start, the filesystem MUST
> load correctly and try to correct the problem, if there's any.
> Yesterday's patch was a step in that direction.
I haven't been able to kill JFFS without a power cycle, so that's what my
testing has concentrated on recently - large concurrent copies and deletion
of data, and pulling the plug in the middle.
Aside from the problem which this hack works around, I've also found it
gets confused when it encounters an erase block which is only partially
erased because the power was lost half way through the erase cycle. The
data in the block tend to look something like FFFBFFCFFFF7FFF...