[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3fs crash with lots of mmap/munmap/unlink activity



Hi,

On Fri, Jul 13, 2001 at 12:24:21AM +0200, Jasper Spaans wrote:
> 
> It seems the current ext3 code has some problems; my machine is running
> 2.4.6-ac1 with ext3-0.9 patches on top of it. This afternoon, I was doing
> some testing of a little piece of code on my machine, and I was able to
> crash it.

Does the attached patch (which is already in ext3 CVS, both on the
head and in the 0.9 branch) help?  I've been doing mmap-heavy stress
testing over the past couple of days and have had no problems with
this patch applied.  (It affects concurrent access to sparse files,
with a pattern which mmap tends to lead to.)

> I'm having some troubles catching the oops, either the serial port of my
> laptop isn't working correctly anymore, or one of my cats has been playing
> to enthousiasticly with my nullmodem cable.
> 
> Will try to fix that later, or, if that doesn't even work, write down the
> oops manually etc.

Thanks, there's not a lot else I can do without either a complete copy
of a program to reproduce it here, or a crash trace.

Cheers,
 Stephen
Index: fs/ext3/inode.c
===================================================================
RCS file: /cvsroot/gkernel/ext3/fs/ext3/inode.c,v
retrieving revision 1.59
diff -u -r1.59 inode.c
--- fs/ext3/inode.c	2001/07/05 08:12:15	1.59
+++ fs/ext3/inode.c	2001/07/10 11:11:58
@@ -722,20 +722,9 @@
 	}
 
 	/* Next simple case - plain lookup or failed read of indirect block */
-	/*
-	 * AKPM: if it's an I/O error and create != 0, we've journalled any
-	 * changes to the indirect blocks.  Seems that they get written out
-	 * anyway.
-	 */
 	if (!create || err == -EIO) {
 cleanup:
 		while (partial > chain) {
-			if (err == -EIO && handle) {
-				BUFFER_TRACE(partial->bh,
-					"IO error: call ext3_forget");
-				ext3_forget(handle, 1, inode,
-					partial->bh, partial->bh->b_blocknr);
-			}
 			BUFFER_TRACE(partial->bh, "call brelse");
 			brelse(partial->bh);
 			partial--;
@@ -770,6 +759,11 @@
 		goto cleanup;
 	}
 
+	/* The ext3_splice_branch call will free and forget any buffers
+	 * on the new chain if there is a failure, but that risks using
+	 * up transaction credits, especially for bitmaps where the
+	 * credits cannot be returned.  Can we handle this somehow?  We
+	 * may need to return -EAGAIN upwards in the worst case.  --sct */
 	res = ext3_splice_branch(handle, inode, iblock, chain, partial, left);
 	up_read(&inode->u.ext3_i.truncate_sem);
 	if (res < 0)
@@ -789,26 +783,10 @@
 	goto got_it;
 
 changed:
-	/*
-	 * AKPM: have fun testing this path, buddy.
-	 *
-	 * In journal_forget() and friends, we really need a way of asserting
-	 * that this bh is part of a transaction.
-	 */
 	while (partial > chain) {
-		if (create) {
-			BUFFER_TRACE(partial->bh, "call journal_forget");
-			ext3_journal_forget(handle, partial->bh);
-		} else {
-			if (buffer_jbd(partial->bh)) {
-				J_ASSERT_BH(partial->bh,
-				  bh2jh(partial->bh)->b_transaction == 0);
-				J_ASSERT_BH(partial->bh,
-				  bh2jh(partial->bh)->b_next_transaction == 0);
-			}
-			BUFFER_TRACE(partial->bh, "brelsing");
-			brelse(partial->bh);
-		}
+		jbd_debug(1, "buffer chain changed, retrying\n");
+		BUFFER_TRACE(partial->bh, "brelsing");
+		brelse(partial->bh);
 		partial--;
 	}
 	goto reread;

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]