[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
We are having issues with very long write cycles on our flash device and a
lack of a DMA controller. Copying a half megabyte file onto a jffs2
filesystem takes 30-40 seconds with very high CPU utilization.
Given our situation, we are not able to change the hardware configuration
much to accomodate for these long writes (e.g., by adding a DMA
controller, etc). As a result, I have begun writing a write-back cache
implementation in software that will slowly (via a low priority kernel
daemon) trickle data out to the flash device while retaining full cache
coherency. This will allow reasonable response times and an upper-bound to
CPU utilization (which can be changed dynamically) It can be hooked onto
either jffs2 or the mtd device itself.
However, a few questions:
1) Is there a more obvious way to deal with this problem? We have some
other timing-critical software running on the same CPU, so there must be a
cap to the amount of CPU utilization caused by writing to flash. (we're
doing a lot of usleep()s to insure the neccessary timing constraints for
the flash device). Additionally, write()s cannot block for long; we would
like to have a fairly reasonable response time for calls to the filesystem
with the trade-off being low-volume (however possibly bursty) traffic.
2) My write-back cache implementation does not insure ordering of writes
from jffs. Though it should not be excessive, there will be a case where
one write from jffs will complete before a previously-issued write. I'm
working on a way to correct this. Given a power failure, how severe could
this get, even if only a few write()s are out-of-order?
Any thoughts appreciated,
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com