Skip to contentSkip to conversation

New: kernel complains on ENOSPC

Bug 12829 [email protected] 4 participants 11 messages Mar 6, 2009 – Mar 15, 2010 ext4 file system

lore
Share & tools
lore
#0 lore raw

http://bugzilla.kernel.org/show_bug.cgi?id=12829

Summary: kernel complains on ENOSPC
Product: File System
Version: 2.5
KernelVersion: 2.6.29-rc6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]

while copying a few very large files to ext4:

mpage_da_map_blocks block allocation failed for inode 12289 at logical offset 443072 with max blocks 1036 with error -28
This should not happen.!! Data will be lost
Total free blocks count 0
Free/Dirty block details
free_blocks=0
dirty_blocks=1179
Block reservation details
i_reserved_data_blocks=1174
i_reserved_meta_blocks=5
mpage_da_map_blocks block allocation failed for inode 12289 at logical offset 444108 with max blocks 138 with error -28
This should not happen.!! Data will be lost
Total free blocks count 0
Free/Dirty block details
free_blocks=0
dirty_blocks=1179
Block reservation details
i_reserved_data_blocks=1174
i_reserved_meta_blocks=5

haven't dug into it, but this is just ENOSPC; ext4 should be more graceful.

-Eric

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#1 lore raw

[Bug 12829] kernel complains on ENOSPC

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #1 from [email protected] 2009-03-06 15:02 -------
What are the precise reproduction details? We're supposed to keep track of
how many delayed allocation blocks are outstanding, so that we return ENOSPC *before* we get to this stage.

I'm not sure we do the right thing if we mmap into an unallocated region of
file; when do we actually track delayed allocation blocks? The right answer
would be at mmap() time, but OTOH that means if we mmap a 2GB region, do we immediately take a 2GB charge because the process might write into this region?
And does free space returned by 'df' immediately drop by 2GB?

Do you know if there was any allocation by mmap going on in your reproduction
case? That seems the most likely cause to me, if I had to guess....

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#3 lore raw

[Bug 12829] kernel complains on ENOSPC

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #2 from [email protected] 2009-03-06 15:28 ------- It's a series of big files, just doing cp avi foo/* /mnt/ext4fs/bar

It's a user e2image, so won't share the exact fs but will come up w/ a reproducer.

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#2 lore raw

Re: [Bug 12829] kernel complains on ENOSPC

In reply to [email protected]
Quoted 6 lines · On Fri, Mar 06, 2009 at 03:02:21PM -0800, [email protected]…

------- Comment #1 from [email protected] 2009-03-06 15:02 -------
What are the precise reproduction details? We're supposed to keep track of
how many delayed allocation blocks are outstanding, so that we return ENOSPC *before* we get to this stage.

Yes. We should not get the ENOSPC during writeback. That would imply the block reservation is going wrong.

Quoted 6 lines

I'm not sure we do the right thing if we mmap into an unallocated region of
file; when do we actually track delayed allocation blocks? The right answer
would be at mmap() time, but OTOH that means if we mmap a 2GB region, do we immediately take a 2GB charge because the process might write into this region?
And does free space returned by 'df' immediately drop by 2GB?

For mmap block reservation is doing during page_mkwrite.

Quoted 4 lines

Do you know if there was any allocation by mmap going on in your reproduction
case? That seems the most likely cause to me, if I had to guess....

-aneesh

#4 lore raw

[Bug 12829] kernel complains on ENOSPC

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #3 from [email protected] 2009-03-08 22:17 -------

Quoted 6 lines · On Fri, Mar 06, 2009 at 03:02:21PM -0800, [email protected]…

------- Comment #1 from [email protected] 2009-03-06 15:02 -------
What are the precise reproduction details? We're supposed to keep track of
how many delayed allocation blocks are outstanding, so that we return ENOSPC *before* we get to this stage.

Yes. We should not get the ENOSPC during writeback. That would imply the block reservation is going wrong.

Quoted 6 lines

I'm not sure we do the right thing if we mmap into an unallocated region of
file; when do we actually track delayed allocation blocks? The right answer
would be at mmap() time, but OTOH that means if we mmap a 2GB region, do we immediately take a 2GB charge because the process might write into this region?
And does free space returned by 'df' immediately drop by 2GB?

For mmap block reservation is doing during page_mkwrite.

Quoted 4 lines

Do you know if there was any allocation by mmap going on in your reproduction
case? That seems the most likely cause to me, if I had to guess....

-aneesh

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#5 lore raw

[Bug 12829] kernel complains on ENOSPC

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #4 from [email protected] 2009-03-10 09:38 ------- This patch will not fix the problem. But i guess we need this change

-aneesh

fs/ext4/mballoc.c +2 -2
index 4415bee..671f215 100644
@@ -4652,11 +4652,11 @@ out1:
        if (ar->len < inquota)
                DQUOT_FREE_BLOCK(ar->inode, inquota - ar->len);
 out3:
-       if (!ar->len) {
+       if (ar->len < reserv_blks) {
                if (!EXT4_I(ar->inode)->i_delalloc_reserved_flag)
                        /* release all the reserved blocks if non delalloc */
                        percpu_counter_sub(&sbi->s_dirtyblocks_counter,
-                                               reserv_blks);
+                                               reserv_blks - ar->len);
        }
 
        trace_mark(ext4_allocate_blocks,
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
maintainer
#6 lore raw

Re: [Bug 12829] kernel complains on ENOSPC

Aneesh,

What's the status of this patch; do you think we still need it? If so, can you add a proper commit log and signed-off-by, tell me that you've tested it, etc.?

Thanks!!

- Ted

Quoted 39 lines · On Tue, Mar 10, 2009 at 09:38:24AM -0700, [email protected]…

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #4 from [email protected] 2009-03-10 09:38 ------- This patch will not fix the problem. But i guess we need this change

(quoted diff) +0 -1
-aneesh
fs/ext4/mballoc.c +2 -2
index 4415bee..671f215 100644
@@ -4652,11 +4652,11 @@ out1:
        if (ar->len < inquota)
                DQUOT_FREE_BLOCK(ar->inode, inquota - ar->len);
 out3:
-       if (!ar->len) {
+       if (ar->len < reserv_blks) {
                if (!EXT4_I(ar->inode)->i_delalloc_reserved_flag)
                        /* release all the reserved blocks if non delalloc */
                        percpu_counter_sub(&sbi->s_dirtyblocks_counter,
-                                               reserv_blks);
+                                               reserv_blks - ar->len);
        }
 
        trace_mark(ext4_allocate_blocks,
Signature · 8 lines
-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#7 lore raw

Re: [Bug 12829] kernel complains on ENOSPC

Hi Ted,

No we don't need the patch. The patch is wrong. We are actually taking into account the allocated blocks in mballoc.c

3033 */
3034 if (!(ac->ac_flags & EXT4_MB_DELALLOC_RESERVED))
3035 /* release all the reserved blocks if non delalloc */
3036 percpu_counter_sub(&sbi->s_dirtyblocks_counter, reserv_blks);
3037 else {
3038 percpu_counter_sub(&sbi->s_dirtyblocks_counter,
3039 ac->ac_b_ex.fe_len);

-aneesh

Quoted 51 lines · Theodore Tso

Aneesh,

What's the status of this patch; do you think we still need it? If so, can you add a proper commit log and signed-off-by, tell me that you've tested it, etc.?

Thanks!!

- Ted

Quoted 39 lines · On Tue, Mar 10, 2009 at 09:38:24AM -0700, [email protected]…

http://bugzilla.kernel.org/show_bug.cgi?id=12829

------- Comment #4 from [email protected] 2009-03-10 09:38 ------- This patch will not fix the problem. But i guess we need this change

(quoted diff) +0 -1
-aneesh
fs/ext4/mballoc.c +2 -2
index 4415bee..671f215 100644
@@ -4652,11 +4652,11 @@ out1:
        if (ar->len < inquota)
                DQUOT_FREE_BLOCK(ar->inode, inquota - ar->len);
 out3:
-       if (!ar->len) {
+       if (ar->len < reserv_blks) {
                if (!EXT4_I(ar->inode)->i_delalloc_reserved_flag)
                        /* release all the reserved blocks if non delalloc */
                        percpu_counter_sub(&sbi->s_dirtyblocks_counter,
-                                               reserv_blks);
+                                               reserv_blks - ar->len);
        }
 
        trace_mark(ext4_allocate_blocks,
Signature · 8 lines
-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#8 lore raw

Re: [Bug 12829] kernel complains on ENOSPC

Quoted 4 lines · Aneesh Kumar K.V

Hi Ted,

No we don't need the patch. The patch is wrong. We are actually taking into account the allocated blocks in mballoc.c

Ok, thanks. I'll marked the patch as "Rejected" in the ext4 patchwork list. (Patchwork is really great for making sure I don't drop a patch, and I was going through it, and I noticed this patch had been outstanding for the last month.)

- Ted

#9 lore raw

[Bug 12829] kernel complains on ENOSPC

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12829

Theodore Tso <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
         Regression|---                         |No

--- Comment #5 from Theodore Tso <[email protected]> 2009-05-19 19:24:03 ---
Eric --- as a reminder, when you have a chance can you dig into this? This
can cause data loss, so we really should return ENOSPC instead of syslogging the error.

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#10 lore raw

[Bug 12829] kernel complains on ENOSPC

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12829

Eric Sandeen <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #6 from Eric Sandeen <[email protected]> 2010-03-15 20:23:26 --- *** Bug 13604 has been marked as a duplicate of this bug. ***

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.