public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* No free space left for GC
@ 2002-08-17 22:35 Thomas Gleixner
  2002-08-19  9:37 ` Massive file corruption Joakim Tjernlund
  2002-08-19 21:47 ` No free space left for GC Thomas Gleixner
  0 siblings, 2 replies; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-17 22:35 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

Hi David ! 

You wanted to know, why free_size got that low. 

I just copied stuff to an empty partition, until it got full. 
But instead of returning with "not enough space" it keeps garbage 
collection until really no more space is left. 
One of the problems is, that we have at lot of blocks on the dirty list,
with less than 2*sizeof(struct jffs2_raw_inode) left. At scan time we
put these blocks on the clean_list. We must do this in normal operation
too. It's total crap to gc blocks with 4 byte dirty space ! 
The total sum of dirty space is 32K, when we start gc. The most dirty 
block has 1.2k dirty space. Many blocks have less than 512 bytes dirty,
which is the pagesize on my device. This is a result of padding, when we
flush wbuf. The dirty space on blocks with more than 512 byte dirty
space is 12048 Byte, which is less than 1 block. 

The real weird thing is, that we write to the device (from gc) until the
last block is used and we run into an endless loop, where no more space
is left for garbage collection. This happens, because we increase dirty
size during gc instead of decreasing it. Once we are there we cannot
mount the filesystem again, without running in that endless gc loop.

I changed nodemgmt.c so that blocks with less than 2*sizeof(struct
jffs2_raw_inode) dirty space are moved to clean_list. But the gc effect
was still the same. 

Now I noticed that we don't move blocks to the dirty list anymore,
neither on mount (pass1) nor during gc or write. The reason is that
mark_node_obsolete checks if the dirty_size == ref_totlen. Due to the
fact, that we have blocks with some dirty space in the clean list, these
blocks stay there until they are very dirty, which may never happen. I
changed this by checking used space against sector_size -
2*sizeof(struct jffs2_raw_inode). Result is better but not good.
I tried the same procedure on a larger partition (56MB, previous one was
8MB). There I was running in trouble again. I had enough dirty space in
the clean_list, that the check in jffs2_reserve_space c->dirty_size <
c->sector_size never lead to -ENOSPC. I added a check, which is done,
when dirty_size is less than blocksneeded * sector_size. It checks if
the dirty_size in the dirty_lists is > c->sector_size. If not it returns
-ENOSPC too. Same as above.

In both cases, we end up with 3 empty blocks and we can't even remove a
file from the filesystem.

The strange thing is, that the dirty_size is not always correct. When I
filled the filesystem complete, df tells me:
/dev/mtdblock1	8192	8164	28	100%	/mnt/data
The last dirty information from the log was dirty_space = 0x3e0c
After umount and mount I have suddenly dirty_space = 0xcfe8, which is
the real dirty size. The good thing on this is, that the endless gc on a
100% full filesystem stops. The bad thing is that we have only 3 blocks
left and I can't remove a file anymore. Have to add some more checks on
monday.

If we are at the point of a 100% full filesystem and the dirty space is
splitted into small pieces, we add for each gc'd block one or two blocks
to the dirty list and the block, we have written to ends up sometimes on
the dirty list too. Maybe we have to add a check, where we calc the
average dirty space per block on dirty_list. If this is less than a
defined threshold, we return ENOSPC and stop garbage collection instead
of screwing up the filesystem at least. It should always be possible to
delete a file.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Massive file corruption
  2002-08-17 22:35 No free space left for GC Thomas Gleixner
@ 2002-08-19  9:37 ` Joakim Tjernlund
  2002-08-19 21:47 ` No free space left for GC Thomas Gleixner
  1 sibling, 0 replies; 9+ messages in thread
From: Joakim Tjernlund @ 2002-08-19  9:37 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

Hi again

For the second time there has been massive file corrution on one of our
boards.

In /bin there was 3 files that had been corrupted, the first 4K was all zeroes.
In /usr/bin, a ls gave me lots of Input/Output error and a load of CRC
errors in dmesg.

After reboot, ls in /usr/bin did not report Input/Output errors but there
was more corrupted files in there, with the first 4K zeroed.

Before this happened there was a lot of file I/O. ftp files to board, unpack them with rpm
delete old files etc.

No errors was reported during boot by JFFS2. Using the stable branch from ~3-4 months ago.

Any ideas?

            Jocke 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No free space left for GC
  2002-08-17 22:35 No free space left for GC Thomas Gleixner
  2002-08-19  9:37 ` Massive file corruption Joakim Tjernlund
@ 2002-08-19 21:47 ` Thomas Gleixner
  2002-08-19 22:34   ` Thomas Gleixner
       [not found]   ` <015501c247f3$d13176a0$b30210ac@gv.com.tw>
  1 sibling, 2 replies; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-19 21:47 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: David Woodhouse, linux-mtd

Some more information:

I tried to trigger GC instead of flushing the writebuffer. In principle
it works. But when do we stop GC again ? I decided to do it, when the
replacement node is written complete. Fine, if we hit a small file. If
it's rather large, we dirty a lot of space and trigger GC again, if we
are near the GC_TRESHHOLD. So we spend a lot of time in GC and increase
the erasecycles unneccecary. This depends really on the application and
on the filesizes on the filesystem. Padding can make a block dirty too,
but we get rid of the padding during GC, and can produce another
padding, when we run into wbuf_timeout. 

The 0xc4 request is sizeof(jffs2_raw_inode) + JFFS2_MIN_DATA_LEN). This
happens rather often, that it doesn't fit anymore in the block. So we
put this block on the dirty list and raised an endless gc cycle. These
blocks should be put into the clean list.

Then we have a lot of blocks with 4 bytes unused space. These blocks
should definitly always end on the clean list. 

We could put the blocks, which have more than 4 bytes dirty space on the
dirty list at mount time. When a block gets full and has less than 256
byte dirty space, we put it on the clean list to inhibit endless gc
loops on a nearly 100% full filesystem. 

On a 8MB partition I have an average dirty size of 20 bytes in 490
blocks. Not too bad. And more acceptable than loosing 48K, if one 16K
block dies. I have already 2 bad blocks there. So I accept 10k penalty
for having 96K usable flashspace. For NOR this should be no problem as
the sectorsizes are usually 64K - 128K.

On a 64MB partition I ended up with an average dirty size of 14 byte in
3200 blocks, which is a total of 58k. A lot of space, but better than
screwing up if we get near 100%. The 0xc4 request, which does not fit
into the remaining free space hits us too often to ignore it. Better to
have 58k less disk space than no chance to repair my full filesystem
other than erasing it.

The new decision function for gc and reserve_space takes only those
blocks into account, which are on the dirty and very dirty list. The
dirty space in the clean_list is ignored. This is neccecary to avoid
endless GC loops. 

Any suggestions ?

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No free space left for GC
  2002-08-19 21:47 ` No free space left for GC Thomas Gleixner
@ 2002-08-19 22:34   ` Thomas Gleixner
  2002-08-20 10:03     ` David Woodhouse
       [not found]   ` <015501c247f3$d13176a0$b30210ac@gv.com.tw>
  1 sibling, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-19 22:34 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Forgot to attach a diff :)

Last try brought average dirty_space 11 bytes in 492 Blocks in
clean_list. I think we can live with that

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

[-- Attachment #2: cvs.diff --]
[-- Type: text/plain, Size: 10031 bytes --]

? cvs.diff
Index: fs/jffs2/background.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/background.c,v
retrieving revision 1.30
diff -u -r1.30 background.c
--- fs/jffs2/background.c	5 Aug 2002 14:46:47 -0000	1.30
+++ fs/jffs2/background.c	19 Aug 2002 22:30:39 -0000
@@ -155,18 +155,11 @@
 static int thread_should_wake(struct jffs2_sb_info *c)
 {
 	uint32_t gcnodeofs = 0;
-	int ret;
+	int ret = 0;
 
-	/* Don't count any progress we've already made through the gcblock
-	   as dirty space, for the purposes of this calculation */
-	if (c->gcblock && c->gcblock->gc_node)
-		gcnodeofs = c->gcblock->gc_node->flash_offset & ~3 & (c->sector_size-1);
-
-	if (c->nr_free_blocks + c->nr_erasing_blocks < JFFS2_RESERVED_BLOCKS_GCTRIGGER &&
-	    (c->dirty_size - gcnodeofs) > c->sector_size)
+	if (c->nr_free_blocks + c->nr_erasing_blocks < JFFS2_RESERVED_BLOCKS_GCTRIGGER && 
+		!jffs2_gc_checkspace (c, JFFS2_RESERVED_BLOCKS_BASE))
 		ret = 1;
-	else 
-		ret = 0;
 
 	D1(printk(KERN_DEBUG "thread_should_wake(): nr_free_blocks %d, nr_erasing_blocks %d, dirty_size 0x%x (mod 0x%x): %s\n", 
 		  c->nr_free_blocks, c->nr_erasing_blocks, c->dirty_size,
Index: fs/jffs2/build.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
retrieving revision 1.36
diff -u -r1.36 build.c
--- fs/jffs2/build.c	7 Aug 2002 18:37:32 -0000	1.36
+++ fs/jffs2/build.c	19 Aug 2002 22:30:40 -0000
@@ -43,6 +43,7 @@
 		return ret;
 
 	D1(printk(KERN_DEBUG "Scanned flash completely\n"));
+	D1(jffs2_dump_block_lists(c));
 	/* Now build the data map for each inode, marking obsoleted nodes
 	   as such, and also increase nlink of any children. */
 	for_each_inode(i, c, ic) {
@@ -54,7 +55,8 @@
 		}
 	}
 	D1(printk(KERN_DEBUG "Pass 1 complete\n"));
-
+	D1(jffs2_dump_block_lists(c));
+	
 	/* Next, scan for inodes with nlink == 0 and remove them. If
 	   they were directories, then decrement the nlink of their
 	   children too, and repeat the scan. As that's going to be
@@ -75,6 +77,7 @@
 		   and furthermore that it had children and their nlink has now
 		   gone to zero too. So we have to restart the scan. */
 		} 
+		D1(jffs2_dump_block_lists(c));
 	} while(ret == -EAGAIN);
 	
 	D1(printk(KERN_DEBUG "Pass 2 complete\n"));
@@ -99,6 +102,7 @@
 		kfree(scan);
 	}
 	D1(printk(KERN_DEBUG "Pass 3 complete\n"));
+	D1(jffs2_dump_block_lists(c));
 
 	/* Rotate the lists by some number to ensure wear levelling */
 	jffs2_rotate_lists(c);
Index: fs/jffs2/gc.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/gc.c,v
retrieving revision 1.78
diff -u -r1.78 gc.c
--- fs/jffs2/gc.c	7 Aug 2002 11:01:14 -0000	1.78
+++ fs/jffs2/gc.c	19 Aug 2002 22:30:42 -0000
@@ -33,6 +33,40 @@
 				       struct jffs2_inode_info *f, struct jffs2_full_dnode *fn,
 				       uint32_t start, uint32_t end);
 
+/* Check, if we have enough dirty space for GC */
+int jffs2_gc_checkspace (struct jffs2_sb_info *c, int blocksneeded)
+{
+	
+	if (c->dirty_size < blocksneeded * c->sector_size) {
+		
+		uint32_t dirty = 0;
+		struct list_head *this;
+		
+		if (!list_empty(&c->very_dirty_list)) {
+			list_for_each(this, &c->very_dirty_list) {
+				struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+				dirty += jeb->dirty_size;
+			}
+		}
+		if (!list_empty(&c->dirty_list)) {
+			list_for_each(this, &c->dirty_list) {
+				struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+				dirty += jeb->dirty_size;	
+			}
+		}
+		/* Add dirty size of current gc-block */
+		if (c->gcblock)
+			dirty += c->gcblock->dirty_size;
+					
+		if (dirty < c->sector_size) {
+			D1(printk(KERN_DEBUG "dirty size in dirty_lists 0x%08x < sector size 0x%08x\n", dirty, c->sector_size));
+			return 1;
+		}
+	}
+	/* yep, we can GC */
+	return 0;
+}
+
 /* Called with erase_completion_lock held */
 static struct jffs2_eraseblock *jffs2_find_gc_block(struct jffs2_sb_info *c)
 {
Index: fs/jffs2/nodelist.h
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodelist.h,v
retrieving revision 1.75
diff -u -r1.75 nodelist.h
--- fs/jffs2/nodelist.h	17 Aug 2002 22:28:04 -0000	1.75
+++ fs/jffs2/nodelist.h	19 Aug 2002 22:30:43 -0000
@@ -220,8 +220,9 @@
 /* How much dirty space before it goes on the very_dirty_list */
 #define VERYDIRTY(c, size) ((size) >= ((c)->sector_size / 2))
 
-/* check if unused space is more than sector - 2 * sizeof(struct jffs2_raw_inode) */
-#define ISDIRTY(c, size) ((size) < c->sector_size - (2 * sizeof(struct jffs2_raw_inode)))
+/* check if unused space is more than 256 Byte */
+#define ISDIRTY(c, size) ((size) < c->sector_size - 255) 
+#define MNTISDIRTY(c, size) ((size) < c->sector_size - 4) 
 
 #define PAD(x) (((x)+3)&~3)
 
@@ -299,6 +300,7 @@
 
 /* gc.c */
 int jffs2_garbage_collect_pass(struct jffs2_sb_info *c);
+int jffs2_gc_checkspace (struct jffs2_sb_info *c, int blocksneeded);
 
 /* read.c */
 int jffs2_read_dnode(struct jffs2_sb_info *c, struct jffs2_full_dnode *fd, unsigned char *buf, int ofs, int len);
Index: fs/jffs2/nodemgmt.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodemgmt.c,v
retrieving revision 1.71
diff -u -r1.71 nodemgmt.c
--- fs/jffs2/nodemgmt.c	17 Aug 2002 22:32:11 -0000	1.71
+++ fs/jffs2/nodemgmt.c	19 Aug 2002 22:30:44 -0000
@@ -62,32 +62,13 @@
 			int ret;
 
 			up(&c->alloc_sem);
-			if (c->dirty_size < c->sector_size) {
-				D1(printk(KERN_DEBUG "Short on space, but total dirty size 0x%08x < sector size 0x%08x, so -ENOSPC\n", c->dirty_size, c->sector_size));
+			
+			if (jffs2_gc_checkspace(c, blocksneeded)) {
+				D1(printk (KERN_DEBUG "Too little dirty_space for GC, returning -ENOSPC\n"));
 				spin_unlock_bh(&c->erase_completion_lock);
 				return -ENOSPC;
 			}
-			if (c->dirty_size < blocksneeded * c->sector_size) {
-				uint32_t dirty = 0;			
-				struct list_head *this;
-				if (!list_empty(&c->very_dirty_list)) {
-					list_for_each(this, &c->very_dirty_list) {
-						struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
-						dirty += jeb->dirty_size;	
-					}
-				}
-				if (!list_empty(&c->dirty_list)) {
-					list_for_each(this, &c->dirty_list) {
-						struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
-						dirty += jeb->dirty_size;	
-					}
-				}
-				if (dirty < c->sector_size) {
-					D1(printk(KERN_DEBUG "Short on space, but dirty size in dirty_lists 0x%08x < sector size 0x%08x, so -ENOSPC\n", dirty, c->sector_size));
-					spin_unlock_bh(&c->erase_completion_lock);
-					return -ENOSPC;
-				}
-			}
+			
 			D1(printk(KERN_DEBUG "Triggering GC pass. nr_free_blocks %d, nr_erasing_blocks %d, free_size 0x%08x, dirty_size 0x%08x, used_size 0x%08x, erasing_size 0x%08x, bad_size 0x%08x (total 0x%08x of 0x%08x)\n",
 				  c->nr_free_blocks, c->nr_erasing_blocks, c->free_size, c->dirty_size, c->used_size, c->erasing_size, c->bad_size,
 				  c->free_size + c->dirty_size + c->used_size + c->erasing_size + c->bad_size, c->flash_size));
@@ -498,6 +479,8 @@
 #if CONFIG_JFFS2_FS_DEBUG > 0
 void jffs2_dump_block_lists(struct jffs2_sb_info *c)
 {
+
+
 	printk(KERN_DEBUG "jffs2_dump_block_lists:\n");
 	printk(KERN_DEBUG "flash_size: %08x\n", c->flash_size);
 	printk(KERN_DEBUG "used_size: %08x\n", c->used_size);
@@ -522,31 +505,46 @@
 		printk(KERN_DEBUG "clean_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->clean_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "clean_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->very_dirty_list)) {
 		printk(KERN_DEBUG "very_dirty_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->very_dirty_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "very_dirty_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->dirty_list)) {
 		printk(KERN_DEBUG "dirty_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->dirty_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "dirty_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->erasable_list)) {
 		printk(KERN_DEBUG "erasable_list: empty\n");
Index: fs/jffs2/scan.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/scan.c,v
retrieving revision 1.80
diff -u -r1.80 scan.c
--- fs/jffs2/scan.c	17 Aug 2002 22:29:28 -0000	1.80
+++ fs/jffs2/scan.c	19 Aug 2002 22:30:47 -0000
@@ -420,7 +420,7 @@
 	if (jeb->used_size == PAD(sizeof(struct jffs2_unknown_node)) && 
 	    !jeb->first_node->next_in_ino && !jeb->dirty_size)
 		return BLK_STATE_CLEANMARKER;
-	else if (!ISDIRTY(c, jeb->used_size)) 
+	else if (!MNTISDIRTY(c, jeb->used_size)) 
 		return BLK_STATE_CLEAN;
 	else if (jeb->used_size)
 		return BLK_STATE_PARTDIRTY;

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No free space left for GC
       [not found]   ` <015501c247f3$d13176a0$b30210ac@gv.com.tw>
@ 2002-08-20  7:59     ` Thomas Gleixner
  2002-08-20 15:47       ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-20  7:59 UTC (permalink / raw)
  To: 小明; +Cc: linux-mtd

On Tue, 2002-08-20 at 04:46, 小明 wrote:
> in our own old nand flash system
> we always keep 1 nand-flash-block for garbage collection in block device
> driver
> (8k/8MB,16k/64MB)
> it never endless gc, but when diskfull,the speed is really slow
> finally we reserved more space(512k) for gc to  make gc faster
> those reversed space is not showed in fs layer
> we report (real size-reserved space) to fs layer
> and we use minix as fs layer
> (we do  bad block management, wear leveling, error correction,
> all in block device driver not in fs layer)
> recently, we need compression , so we try jffs2:)
> i think the design of jffs2 is also better than our old one:)
1. Please keep answers to mailinglist posting on the list. Thanks.

2. The endless gc, which used up all blocks, is fixed now. I will do
some more tests and put a final version into CVS today.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No free space left for GC
  2002-08-19 22:34   ` Thomas Gleixner
@ 2002-08-20 10:03     ` David Woodhouse
  0 siblings, 0 replies; 9+ messages in thread
From: David Woodhouse @ 2002-08-20 10:03 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: linux-mtd

tglx@linutronix.de said:
>  The new decision function for gc and reserve_space takes only those
> blocks into account, which are on the dirty and very dirty list. The
> dirty space in the clean_list is ignored. This is neccecary to avoid
> endless GC loops. 

> Any suggestions ?

<IRC conversation repeated, for the benefit of the peanut gallery>

Nice work, thanks. If this fixes the problem, as I believe it does, please
don't calculate the dirty size in thread_should_wake() -- use c->dirty_size 
and just don't count the wasted space in the end of blocks on the 
clean_list in that; add something like 'wasted_size' to keep track of that
instead.

And read README.Locking again. It's rare that I actually write sensible 
documentation -- make the most of it :)

--
dwmw2

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: No free space left for GC
  2002-08-20  7:59     ` Thomas Gleixner
@ 2002-08-20 15:47       ` Thomas Gleixner
  2002-08-21  6:44         ` can i use the cvs code directly in kernel 2.2.19 ? 小明
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-20 15:47 UTC (permalink / raw)
  To: 小明; +Cc: linux-mtd

On Tue, 2002-08-20 at 09:59, Thomas Gleixner wrote:
> 2. The endless gc, which used up all blocks, is fixed now. I will do
> some more tests and put a final version into CVS today.
Is there, please try again. 

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

* can i use the cvs code directly in kernel 2.2.19 ?
  2002-08-20 15:47       ` Thomas Gleixner
@ 2002-08-21  6:44         ` 小明
  2002-08-21  7:56           ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: 小明 @ 2002-08-21  6:44 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: linux-mtd

dear all,
another question:
can i use the cvs code directly in kernel 2.2.19 ?
(currently it work fine with kernel 2.4.17)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: can i use the cvs code directly in kernel 2.2.19 ?
  2002-08-21  6:44         ` can i use the cvs code directly in kernel 2.2.19 ? 小明
@ 2002-08-21  7:56           ` Thomas Gleixner
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2002-08-21  7:56 UTC (permalink / raw)
  To: 小明; +Cc: linux-mtd

On Wed, 2002-08-21 at 08:44, 小明 wrote:
> dear all,
> another question:
> can i use the cvs code directly in kernel 2.2.19 ?
> (currently it work fine with kernel 2.4.17)
Look for the inter_module patch in the patches/ directory of CVS.
It's for 2.2.17, but should apply to 2.2.19 too. There are some more
tweaks neccecary. There are 2 mailthreads (june, august 02) about that.
Citation dwmw2:
> I know of nobody else working on a 2.2 backport. Worst case, you 
> should be able to ditch the page-based write code and call
> jffs2_write_file_range() from a jffs2_file_write() which you provide
> instead of generic_file_write().

BTW, did you test latest code in CVS ? Any problems left ?

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2002-08-21  7:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-17 22:35 No free space left for GC Thomas Gleixner
2002-08-19  9:37 ` Massive file corruption Joakim Tjernlund
2002-08-19 21:47 ` No free space left for GC Thomas Gleixner
2002-08-19 22:34   ` Thomas Gleixner
2002-08-20 10:03     ` David Woodhouse
     [not found]   ` <015501c247f3$d13176a0$b30210ac@gv.com.tw>
2002-08-20  7:59     ` Thomas Gleixner
2002-08-20 15:47       ` Thomas Gleixner
2002-08-21  6:44         ` can i use the cvs code directly in kernel 2.2.19 ? 小明
2002-08-21  7:56           ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox