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