diff mbox

EXT4 ENOSPC Bug

Message ID 20081203172309.GB30610@mit.edu
State Not Applicable, archived
Headers show

Commit Message

Theodore Ts'o Dec. 3, 2008, 5:23 p.m. UTC 
On Wed, Dec 03, 2008 at 09:04:41PM +0530, Aneesh Kumar K.V wrote:
> 
> Can you make sure you have the below patch in the kernel.
> 
> c001077f4003fa75793bb62979baa6241dd8eb19
> 
> commit c001077f4003fa75793bb62979baa6241dd8eb19
> Author: Eric Sandeen <sandeen@redhat.com>
> Date:   Tue Aug 19 22:19:50 2008 -0400
> 
> ext4: Fix bug where we return ENOSPC even though we have plenty of inodes
> 

Mmmm, good point, thanks.  I had been assuming this was caused by some
failure in the delayed allocation code with block accounting, but we
also had a bug fix that was causing a problem with inode allocation.

That doesn't explain a report of an ENOSPC error with metadata only
changes were failing (i.e., touching a file that already exists),
although I don't think we've gotten a lot of information about that
scenario and it feels a little unconfirmed to me still...

So, yes, this patch may solve the issue for you.

							- Ted

Comments

Andres Freund Dec. 3, 2008, 6:18 p.m. UTC | #1 
On Wednesday 03 December 2008 18:23:09 Theodore Tso wrote:
> On Wed, Dec 03, 2008 at 09:04:41PM +0530, Aneesh Kumar K.V wrote:
> > Can you make sure you have the below patch in the kernel.
> > c001077f4003fa75793bb62979baa6241dd8eb19
Yes, I do have that patch in kernel (verified through git and looking at the 
source). Its a part of linus' tree.

> Mmmm, good point, thanks.  I had been assuming this was caused by some
> failure in the delayed allocation code with block accounting, but we
> also had a bug fix that was causing a problem with inode allocation.
>
> That doesn't explain a report of an ENOSPC error with metadata only
> changes were failing (i.e., touching a file that already exists),
> although I don't think we've gotten a lot of information about that
> scenario and it feels a little unconfirmed to me still...
Unfortunately I am not absolutely sure (I reported this) as well, this is the 
reason I did not report it at first but only after no culprit could be found.

Still no luck reproducing it once more.


Andres
diff mbox

Patch

From c001077f4003fa75793bb62979baa6241dd8eb19 Mon Sep 17 00:00:00 2001
From: Eric Sandeen <sandeen@redhat.com>
Date: Tue, 19 Aug 2008 22:19:50 -0400
Subject: [PATCH] ext4: Fix bug where we return ENOSPC even though we have plenty of inodes

The find_group_flex() function starts with best_flex as the
parent_fbg_group, which happens to have 0 inodes free.  Some of the
flex groups searched have free blocks and free inodes, but the
flex_freeb_ratio is < 10, so they're skipped.  Then when a group is
compared to the current "best" flex group, it does not have more free
blocks than "best", so it is skipped as well.

This continues until no flex group with free inodes is found which has
a proper ratio or which has more free blocks than the "best" group,
and we're left with a "best" group that has 0 inodes free, and we
return -ENOSPC.

We fix this by changing the logic so that if the current "best" flex
group has no inodes free, and the current one does have room, it is
promoted to the next "best."

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
 fs/ext4/ialloc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 655e760..f344834 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -351,7 +351,7 @@  find_close_to_parent:
 			goto found_flexbg;
 		}
 
-		if (best_flex < 0 ||
+		if (flex_group[best_flex].free_inodes == 0 ||
 		    (flex_group[i].free_blocks >
 		     flex_group[best_flex].free_blocks &&
 		     flex_group[i].free_inodes))
-- 
1.6.0.4.8.g36f27.dirty