[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: JFFS is not broken (Was: JFFS broken?)
I am guessing here, but are you by any chance using burst read towards
If you are, I would like to know how you have done that. I understand
that it involves mapping the flash to 2 virtual address spaces, one cached and
one uncached. The "copy_from" function should use the cached address space, the
other functions the uncached address space.
Then there is some "cache management magic" that has to be done to avoid
corruption, and here I am lost. What has to be done and why?
Also, does burst reads have any significant impact on performance?
I am using a MPC860 CPU if that has any relevance.
> > email@example.com said:
> > > I get the following warnings when compiling (maybe it has
> > something to
> > > do with the problems I'm having):
> My problems with JFFS was caused by two things:
> - Later versions of JFFS sometimes causes flash writes of one byte at an odd address.
> Our copy_from function was reading cached data that was out of date. (Yes that was
> exacly what you pointed out in the "missing cache flush" thread at the linux-kernel
> list a while back). I'm sorry I wasted your time with this one.
> - The number of reserved blocks has increased. We have been using a JFFS partition of
> 5 blocks for ages. But with latest JFFS we would have to increase the partition not
> to get ENOSPC after a couple of writes. I have read the discusions about this and
> I think I understand the problem. But since we haven't had any problem using only
> 5 blocks before I think I'll stick to that.
> Does JFFS ever fragment inodes when doing garbage collect?
> Best regards
> To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
> the body of a message to firstname.lastname@example.org
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com