RE: intrep.c update to handle gaps in the middle of the log.

RE: intrep.c update to handle gaps in the middle of the log.

[Simon Munton]

This update seems to bring about another problem.

My flash image (size = 0x7e0000) looks like this:
	0x000000 - 0x2c8cff:	valid nodes
	0x2c8d00 - 0x75ffff:	all 0xff
	0x760000 - 0x76049f:	all zero
	0x7604a0 - 0x7dffff:	valid nodes

With this update it results in the whole 0xff area being treated as dirty.
If I try and copy a file on to it, it reports that the file system is full. 

garbage collection doesn't. 

debug output looks like this (and this message is repeated every few
seconds):
	***jffs_garbage_collect(): round #1, fmc->dirty_size = 4815352
	struct jffs_fmcontrol: 0xc0093590
	{
        0x00000000, /* flash_start  */
        8257536, /* flash_size  */
        3442184, /* used_size  */
        4815352, /* dirty_size  */
        131072, /* sector_size  */
        196608, /* min_free_size  */
        65536, /* max_chunk_size  */
        0xc01cf700, /* mtd  */
        0xc03adf30, /* head  */    (head->offset = 0x00000000)
        0xc0f6b9e0, /* tail  */    (tail->offset + tail->size = 0x007e0000)
        0x00000000, /* head_extra  */
        0x00000000, /* tail_extra  */
	}
	jffs_try_to_erase(): erase_size = 0
	   jffs_garbage_collect(): erased: 0, free_size: 0

I think you need to restrict the amount of space treated as dirty to be in a
single erase sector. Also, if the end of the area is at an erase sector
boundary, don't treat as dirty at all.
Do you need to check if nodes have already been found? Won't you also get
the problem at the very start of the flash? (your original failure happened
when you powered off mid update - but the sector being updated could easily
have been the very first one).

Simon

========================================================
Simon Munton				simonm@m4data.co.uk
M4 Data Ltd					Tel: 44-1749-683800
Mendip Court, Bath Rd, Wells		Fax: 44-1749-673928
Somerset, BA5 3DG, England



-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: 26 July 2000 04:36 pm
To: jffs-dev@axis.com
Subject: intrep.c update to handle gaps in the middle of the log.


This appears to fix the problem for me, so I've committed it to CVS. 

Index: intrep.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/intrep.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -w -r1.23 -r1.24
--- intrep.c	2000/07/26 15:02:10	1.23
+++ intrep.c	2000/07/26 15:34:10	1.24
@@ -10,7 +10,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * $Id: intrep.c,v 1.23 2000/07/26 15:02:10 dwmw2 Exp $
+ * $Id: intrep.c,v 1.24 2000/07/26 15:34:10 dwmw2 Exp $
  *
  * Ported to Linux 2.3.x and MTD:
  * Copyright (C) 2000  Alexander Larsson (alex@cendio.se), Cendio Systems
AB
@@ -626,6 +626,20 @@
 			     pos += 4);
 			D1(printk("jffs_scan_flash(): 0xff ended at "
 				  "pos 0x%lx.\n", (long)pos));
+
+			/* Added by dwmw2: if we have already found nodes, 
+			   then treat this space as dirty rather than clean,
+			   unless it extends to the very end of the flash.
+			   This is to handle the case where one thread 
+			   allocated space for a node, but didn't get to
+			   actually _write_ it before power was lost,
leaving
+			   a gap in the log. Shifting all node writes into
+			   a single kernel thread will fix the original
problem.+			*/
+			if (fmc->head && pos < end) {
+				jffs_fmalloced(fmc, (__u32) start,
+					       (__u32) (pos - start), 0);
+			}
 			continue;
 
 		case JFFS_DIRTY_BITMASK:


--
dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: intrep.c update to handle gaps in the middle of the log.

[Sébastien Côté]

Simon Munton wrote:
> 
> This update seems to bring about another problem.
> 
> My flash image (size = 0x7e0000) looks like this:
>         0x000000 - 0x2c8cff:    valid nodes
>         0x2c8d00 - 0x75ffff:    all 0xff
>         0x760000 - 0x76049f:    all zero
>         0x7604a0 - 0x7dffff:    valid nodes
> 
> With this update it results in the whole 0xff area being treated as dirty.
> If I try and copy a file on to it, it reports that the file system is full.
> 
> I think you need to restrict the amount of space treated as dirty to be in a
> single erase sector. Also, if the end of the area is at an erase sector
> boundary, don't treat as dirty at all.
> Do you need to check if nodes have already been found? Won't you also get
> the problem at the very start of the flash? (your original failure happened
> when you powered off mid update - but the sector being updated could easily
> have been the very first one).

Our original problem was a "hole" between two valid nodes (we forgot to
check if the data that followed was valid in the patch) but you're
right, it could happen to the first sector.  Maybe we should only check
if a free space ends in the middle of a sector.  In that case, treat the
beginning of that sector as dirty.  Would that do the trick?

If we have :

>         0x000000 - 0x2b0000:    valid nodes
>         0x2b0000 - 0x2b7000:    all 0xff	The error occured here
>         0x2b7000 - 0x2c0000:    all zero      We set this space as dirty
>	  0x2c0000 - 0x2c8cff:    valid nodes
>         0x2c8d00 - 0x75ffff:    all 0xff
>         0x760000 - 0x76049f:    all zero
>         0x7604a0 - 0x7dffff:    valid nodes

(Suppose all dirty space and valid nodes starts on the beginning of a
sector, I didn't want to do the math)

Would the filesystem be mounted correctly or do we _have_ to set the
first free space (where the error occured) as dirty too ? 

-- 
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: intrep.c update to handle gaps in the middle of the log.

[Simon Munton]

> -----Original Message-----
> From: Sébastien Côté [mailto:scote1@Matrox.COM]
> Sent: 27 July 2000 02:27 pm
> 
> 
> Our original problem was a "hole" between two valid nodes (we 
> forgot to
> check if the data that followed was valid in the patch) but you're
> right, it could happen to the first sector.  Maybe we should 
> only check
> if a free space ends in the middle of a sector.  In that 
> case, treat the
> beginning of that sector as dirty.  Would that do the trick?

Yes, I think it would.

> 
> If we have :
> 
> >         0x000000 - 0x2b0000:    valid nodes
> >         0x2b0000 - 0x2b7000:    all 0xff	The error occured here
> >         0x2b7000 - 0x2c0000:    all zero      We set this 
> space as dirty
> >	  0x2c0000 - 0x2c8cff:    valid nodes
> >         0x2c8d00 - 0x75ffff:    all 0xff
> >         0x760000 - 0x76049f:    all zero
> >         0x7604a0 - 0x7dffff:    valid nodes
> 
> (Suppose all dirty space and valid nodes starts on the beginning of a
> sector, I didn't want to do the math)
> 
> Would the filesystem be mounted correctly or do we _have_ to set the
> first free space (where the error occured) as dirty too ? 

In this case, how does JFFS decide where the end of the log is? Is it at the
start of the first free space, or the second? My gut reaction would be to
set all but the largest of the free spaces to be dirty.

Simon
 


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: intrep.c update to handle gaps in the middle of the log.

[Sébastien Côté]

Simon Munton wrote:
> >
> > If we have :
> >
> > >         0x000000 - 0x2b0000:    valid nodes
> > >         0x2b0000 - 0x2b7000:    all 0xff    The error occured here
> > >         0x2b7000 - 0x2c0000:    all zero      We set this
> > space as dirty
> > >       0x2c0000 - 0x2c8cff:    valid nodes
> > >         0x2c8d00 - 0x75ffff:    all 0xff
> > >         0x760000 - 0x76049f:    all zero
> > >         0x7604a0 - 0x7dffff:    valid nodes
> >
> In this case, how does JFFS decide where the end of the log is? Is it at the
> start of the first free space, or the second? My gut reaction would be to
> set all but the largest of the free spaces to be dirty.

That seems correct to me, if you also set dirty the free space at the
beginning of the corrupted sector.

-- 
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org