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
--
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.
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....
--
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.
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.
--
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.
On Fri, Mar 06, 2009 at 03:02:21PM -0800, [email protected] wrote:
>
>
> ------- 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.
>
> 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.
>
> 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
http://bugzilla.kernel.org/show_bug.cgi?id=12829
------- Comment #3 from [email protected] 2009-03-08 22:17 -------
On Fri, Mar 06, 2009 at 03:02:21PM -0800, [email protected]
wrote:
>
>
> ------- 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.
>
> 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.
>
> 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
--
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.
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
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 4415bee..671f215 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -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,
--
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.
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
On Tue, Mar 10, 2009 at 09:38:24AM -0700, [email protected] wrote:
> 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
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 4415bee..671f215 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -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,
>
>
> --
> 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
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
On Mon, Apr 06, 2009 at 02:58:23PM -0400, Theodore Tso wrote:
> 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
>
>
> On Tue, Mar 10, 2009 at 09:38:24AM -0700, [email protected] wrote:
> > 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
> >
> > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> > index 4415bee..671f215 100644
> > --- a/fs/ext4/mballoc.c
> > +++ b/fs/ext4/mballoc.c
> > @@ -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,
> >
> >
> > --
> > 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
On Tue, Apr 07, 2009 at 08:01:46PM +0530, Aneesh Kumar K.V wrote:
> 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
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.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
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. ***
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.