No clean _or_ dirty blocks to GC from!

No clean _or_ dirty blocks to GC from!

[Larry Doolittle]

This is really strange.  I go through the following steps:

0. Run linux-2.4.9-ac10-rmk2-np1 with latest CVS MTD/JFFS2 on a
   StrongARM with Intel 28F320B3B Flash.  /dev/mtd2 is a 1M partition.

1. eraseall /dev/mtd2
    (works, I can verify all 1's in the 16 64K blocks)

2. cp image /dev/mtd2
    (image created with mkfs.jffs2.  Seems to work)

3. mount -t jffs2 /dev/mtdblock2 /mnt/test

mtdblock_open
ok
jffs2: No clean _or_ dirty blocks to GC from! Where are they all?
jffs2: Couldn't find erase block to garbage collect!

   The files are there.

4. umount /mnt/test
    (works)

5. check the blocks -- the 15 blocks that were all 1's before
   all now have at the beginning:

begin 644 foo
@A1D#(`P```"QL![D__________________________\`
`
end

$ hexdump foo
0000000 1985 2003 000c 0000 b0b1 e41e ffff ffff
0000010 ffff ffff ffff ffff ffff ffff ffff ffff
0000020

   Wild guess, after reading jffs2.h: these are "clean" markers.
   magic is 0x1985 == JFFS2_MAGIC_BITMASK,
   nodetype is 0x2003 == JFFS2_NODETYPE_CLEANMARKER,
   totlen is 12,
   hdr_crc is 0xe41eb0b1.
   So everything is fine, why the complaint?  And if I mount again,
   I get the same nasty message as before.

Clearly, I'm still a novice at JFFS2.

     - Larry

Re: No clean _or_ dirty blocks to GC from!

[Russ Dill]

On Thu, 2001-10-04 at 09:35, Larry Doolittle wrote:
> This is really strange.  I go through the following steps:
> 
> 0. Run linux-2.4.9-ac10-rmk2-np1 with latest CVS MTD/JFFS2 on a
>    StrongARM with Intel 28F320B3B Flash.  /dev/mtd2 is a 1M partition.

there were some mismerges of mtd in 2.4.9-rmk2-np1 iirc, I had a problem
of mount in checkroot.sh getting stuck in a D state. I would go to a
newer kernel, or grab the latest mtd and put it in the kernel.

Re: No clean _or_ dirty blocks to GC from!

[Larry Doolittle]

On Thu, Oct 04, 2001 at 01:13:54PM -0700, Russ Dill wrote:
> On Thu, 2001-10-04 at 09:35, Larry Doolittle wrote:
> > This is really strange.  I go through the following steps:
> > 
> > 0. Run linux-2.4.9-ac10-rmk2-np1 with latest CVS MTD/JFFS2 on a
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^
> >    StrongARM with Intel 28F320B3B Flash.  /dev/mtd2 is a 1M partition.
> 
> there were some mismerges of mtd in 2.4.9-rmk2-np1 iirc, I had a problem
> of mount in checkroot.sh getting stuck in a D state. I would go to a
> newer kernel, or grab the latest mtd and put it in the kernel.

The linux-2.4.9-ac10-rmk2-np1 had its drivers/mtd, fs/jffs2, and
include/linux/mtd directories deleted, and replaced with those from CVS.
Finally, include/linux/jffs2*.h were copied over.  Is there something that
I could have mis-merged?  

Is there an obvious way to troubleshoot the mount process?  I have
a trace of the mount after giving a "echo 9 >/proc/sys/kernel/printk"
but it's kinda long.  Each block is correctly summarized, here are
the first two:
Block at 0x00000000: free 0x0000e540, dirty 0x00000000, used 0x00001ac0
Block at 0x00010000: free 0x0000fff4, dirty 0x00000000, used 0x0000000c
and of course 0x00020000 through 0x000f0000 are just like 0x00010000.

Oddly, that last run did _not_ give the "No clean _or_ dirty blocks to
GC from!" message.  printk levels 6 and 7 reproducibly give it, but
levels 8 and 9 do not.  printk levels 5 and lower are silent.  Is there
a thread synchronization issue, maybe?

     - Larry

Re: No clean _or_ dirty blocks to GC from!

[Larry Doolittle]

> On Thu, 2001-10-04 at 09:35, Larry Doolittle wrote:
> > This is really strange.  I go through the following steps:

The only problem looks like the message printing.
A GC pass is triggered by the mount process, finds no
garbage to collect, and does nothing.  Perfect!

Possibilities:

1. Change nothing.  The software doesn't get confused, just the operator.

2. Add code to avoid the printk's when there are plenty of _free_ blocks.

3. Don't trigger the GC on mount unless there is something to do.

      - Larry  

Re: No clean _or_ dirty blocks to GC from!

[David Woodhouse]

ldoolitt@recycle.lbl.gov said:
>  Possibilities:
> 1. Change nothing.  The software doesn't get confused, just the
> operator.

Works for me :) But probably not the right thing to do :)

> 2. Add code to avoid the printk's when there are plenty of _free_
> blocks.

Seems sane, if it's necessary. Probably just downgrade it to a debugging 
message.

> 3. Don't trigger the GC on mount unless there is something to do. 

The first thing the thread does on mount is sleep anyway. I'm not sure why 
it's getting woken.

--
dwmw2

Re: No clean _or_ dirty blocks to GC from!

[Larry Doolittle]

> > 3. Don't trigger the GC on mount unless there is something to do. 
> 
> The first thing the thread does on mount is sleep anyway. I'm not sure why 
> it's getting woken.

It doesn't exactly get woken, it just has insomnia.  :-)
This one-liner "fixes" it for me.

      - Larry

--- background.c.orig	Fri Oct  5 10:56:36 2001
+++ background.c	Fri Oct  5 10:56:50 2001
@@ -118,6 +118,7 @@
 		if (!thread_should_wake(c)) {
                         set_current_state (TASK_INTERRUPTIBLE);
 			D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread sleeping...\n"));
+			schedule();
 		}
                 
 		if (current->need_resched)

Re: No clean _or_ dirty blocks to GC from!

[David Woodhouse]

ldoolitt@recycle.lbl.gov said:
>  It doesn't exactly get woken, it just has insomnia.  :-) This
> one-liner "fixes" it for me.

Thanks. I've committed that, with an appropriate comment to make it clear 
that we don't care about the race.

--
dwmw2