JFFS2 and kupdated
Dave Ellis
dge at sixnetio.com
Fri May 9 09:46:04 EDT 2003
On Fri, 2003-05-09 at 13:28, Hans_Peter Urbanek wrote:
> In order not to wait up to five seconds for `kupdated' to become
> active again, I made a change in `jffs2_do_reserve_space'
> fs/jffs2/nodemgmt.c that wakes `kupdated' immediately ...
I am using the patch below for this problem. I have both
RAM and NAND FLASH using JFFS2, and I don't want kupdated
flushing the NAND write cache too often, so I do the
erase immediately instead of waking kupdated.
I only do the immediate erase for RAM devices so that any
clever scheduling for the FLASH devices still works.
A RAM erase is unlikely to schedule() or fail, but I kept
the code to unlock the erase_completion_lock and return
-EAGAIN just in case. It seemed safer to work as much like
the original code as possible.
Dave Ellis
diff -Naur old/nodemgmt.c new/nodemgmt.c
--- nodemgmt.c.orig Fri May 9 09:16:48 2003
+++ nodemgmt.c Fri May 9 09:13:00 2003
@@ -240,6 +240,22 @@
us. We do them ourselves right now. */
jffs2_erase_pending_blocks(c);
#else
+
+ /* It is possible to write to a RAM based device
+ * so quickly that letting kupdate do the
erasing
+ * (every 5 seconds by default) can cause _LONG_
+ * delays here. Instead do the erase right here.
+ */
+ if (c->mtd->type == MTD_RAM) {
+
spin_unlock_bh(&c->erase_completion_lock);
+ jffs2_erase_pending_blocks(c);
+ spin_lock_bh(&c->erase_completion_lock);
+ /* An erase may have failed, decreasing
the
+ amount of free space available. So we
must
+ restart from the beginning */
+ return -EAGAIN;
+ }
+
set_current_state(TASK_INTERRUPTIBLE);
add_wait_queue(&c->erase_wait, &wait);
D1(printk(KERN_DEBUG "Waiting for erases to
complete. erasing_blocks is %d. (erasableempty: %s, erasingempty: %s,
erasependingempty: %s)\n",
More information about the linux-mtd
mailing list