diff mbox

possible (ext4 related?) memory leak in kernel 2.6.26

Message ID 20081006025006.GA9289@mit.edu
State Not Applicable, archived
Headers show

Commit Message

Theodore Ts'o Oct. 6, 2008, 2:50 a.m. UTC
On Sun, Oct 05, 2008 at 06:12:15PM +0200, Quentin Godfroy wrote:
> For the two fs the only inode which shows up is the inode 8 (this
> seems to be the journal. According to 'stat <8>' in debugfs it looks
> like the journal is 134Megs long. I don't remember exactly how I
> created the fs, but i'm sure I did not specified the journal
> size. Does it seem reasonable for a 6,6G fs?

134 Megs sounds wrong.  What does dumpe2fs -h say?  I'm guessing you
didn't calculate it quite correctly.

I did some poking around myself, and noticed that a lot of in-use
buffers hanging around from the journal inode.  The following patch
should fix that problem.  I'm still doing some more testingto make
sure there aren't any other buffer head leaks, but this is seems to
fix the worst of the problems.  Can you let me know how this works for
you?

							- Ted

jbd2: Fix buffer head leak when writing the commit block

Also make sure the buffer heads are marked clean before submitting bh
for writing.  The previous code was marking the buffer head dirty,
which would have forced an unneeded write (and seek) to the journal
for no good reason.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Eric Sandeen Oct. 6, 2008, 3:30 p.m. UTC | #1
Theodore Tso wrote:
> On Sun, Oct 05, 2008 at 06:12:15PM +0200, Quentin Godfroy wrote:
>> For the two fs the only inode which shows up is the inode 8 (this
>> seems to be the journal. According to 'stat <8>' in debugfs it looks
>> like the journal is 134Megs long. I don't remember exactly how I
>> created the fs, but i'm sure I did not specified the journal
>> size. Does it seem reasonable for a 6,6G fs?
> 
> 134 Megs sounds wrong.  What does dumpe2fs -h say?  I'm guessing you
> didn't calculate it quite correctly.
> 
> I did some poking around myself, and noticed that a lot of in-use
> buffers hanging around from the journal inode.  The following patch
> should fix that problem.  I'm still doing some more testingto make
> sure there aren't any other buffer head leaks, but this is seems to
> fix the worst of the problems.  Can you let me know how this works for
> you?
> 
> 							- Ted
> 
> jbd2: Fix buffer head leak when writing the commit block
> 
> Also make sure the buffer heads are marked clean before submitting bh
> for writing.  The previous code was marking the buffer head dirty,
> which would have forced an unneeded write (and seek) to the journal
> for no good reason.
> 
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> index e91f051..c2b04cd 100644
> --- a/fs/jbd2/commit.c
> +++ b/fs/jbd2/commit.c
> @@ -127,8 +127,7 @@ static int journal_submit_commit_record(journal_t *journal,
>  
>  	JBUFFER_TRACE(descriptor, "submit commit block");
>  	lock_buffer(bh);
> -	get_bh(bh);
> -	set_buffer_dirty(bh);
> +	clear_buffer_dirty(bh);
>  	set_buffer_uptodate(bh);
>  	bh->b_end_io = journal_end_buffer_io_sync;
>  
> @@ -157,7 +156,7 @@ static int journal_submit_commit_record(journal_t *journal,
>  
>  		/* And try again, without the barrier */
>  		lock_buffer(bh);
> -		set_buffer_uptodate(bh);
> +		clear_buffer_uptodate(bh);
>  		set_buffer_dirty(bh);
>  		ret = submit_bh(WRITE, bh);
>  	}

Just so it doesn't get lost (discussed w/ Ted today) I think this 2nd
hunk flipped the wrong buffer funtion; this makes much more sense to me:

@@ -157,7 +156,7 @@ static int journal_submit_commit_record(journal_t
*journal,

 		/* And try again, without the barrier */
 		lock_buffer(bh);
		set_buffer_uptodate(bh);
-		set_buffer_dirty(bh);
+		clear_buffer_dirty(bh);
 		ret = submit_bh(WRITE, bh);
 	}


-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Renato S. Yamane Oct. 6, 2008, 3:50 p.m. UTC | #2
Theodore Tso wrote:
> Quentin Godfroy wrote:
>> For the two fs the only inode which shows up is the inode 8 (this
>> seems to be the journal. According to 'stat <8>' in debugfs it looks
>> like the journal is 134Megs long. I don't remember exactly how I
>> created the fs, but i'm sure I did not specified the journal
>> size. Does it seem reasonable for a 6,6G fs?
>
> 134 Megs sounds wrong.  What does dumpe2fs -h say?  I'm guessing you
> didn't calculate it quite correctly.

I'm running 2.6.26.2 (ext3) and dumpe2fs show me:
Journal size: 128M

# fdisk -l

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cilindros of 16065 * 512 = 8225280 bytes
Disk identifier: 0xe5d80ea3

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sda1               1         889     7139328   27  Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2   *         889        4780    31250000    7  HPFS ou NTFS
Partition 2 does not end on cylinder boundary.
/dev/sda3            4781        7212    19527480   83  Linux
Partition 3 does not end on cylinder boundary.
/dev/sda4            7212       12161    39758040    5  Extended
Partition 4 does not end on cylinder boundary.
/dev/sda5            7212        7274      498928+  82  Linux swap
/dev/sda6            7274       12161    39259048+  83  Linux

Regards,
Renato
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
diff mbox

Patch

diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index e91f051..c2b04cd 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -127,8 +127,7 @@  static int journal_submit_commit_record(journal_t *journal,
 
 	JBUFFER_TRACE(descriptor, "submit commit block");
 	lock_buffer(bh);
-	get_bh(bh);
-	set_buffer_dirty(bh);
+	clear_buffer_dirty(bh);
 	set_buffer_uptodate(bh);
 	bh->b_end_io = journal_end_buffer_io_sync;
 
@@ -157,7 +156,7 @@  static int journal_submit_commit_record(journal_t *journal,
 
 		/* And try again, without the barrier */
 		lock_buffer(bh);
-		set_buffer_uptodate(bh);
+		clear_buffer_uptodate(bh);
 		set_buffer_dirty(bh);
 		ret = submit_bh(WRITE, bh);
 	}