[Bug 12829] New: kernel complains on ENOSPC

[Bug 12829] New: kernel complains on ENOSPC

[bugme-daemon]

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: fs_ext4@kernel-bugs.osdl.org
        ReportedBy: sandeen@redhat.com


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.

[Bug 12829] kernel complains on ENOSPC

[bugme-daemon]

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





------- Comment #1 from tytso@mit.edu  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.

[Bug 12829] kernel complains on ENOSPC

[bugme-daemon]

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





------- Comment #2 from sandeen@redhat.com  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.

Re: [Bug 12829] kernel complains on ENOSPC

[Aneesh Kumar K.V]

On Fri, Mar 06, 2009 at 03:02:21PM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> 
> 
> ------- Comment #1 from tytso@mit.edu  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

[Bug 12829] kernel complains on ENOSPC

[bugme-daemon]

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





------- Comment #3 from aneesh.kumar@linux.vnet.ibm.com  2009-03-08 22:17 -------
On Fri, Mar 06, 2009 at 03:02:21PM -0800, bugme-daemon@bugzilla.kernel.org
wrote:
> 
> 
> ------- Comment #1 from tytso@mit.edu  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.

[Bug 12829] kernel complains on ENOSPC

[bugme-daemon]

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





------- Comment #4 from aneesh.kumar@linux.vnet.ibm.com  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.

Re: [Bug 12829] kernel complains on ENOSPC

[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


On Tue, Mar 10, 2009 at 09:38:24AM -0700, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12829
> 
> 
> 
> 
> 
> ------- Comment #4 from aneesh.kumar@linux.vnet.ibm.com  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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 12829] kernel complains on ENOSPC

[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 

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, bugme-daemon@bugzilla.kernel.org wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=12829
> > 
> > 
> > 
> > 
> > 
> > ------- Comment #4 from aneesh.kumar@linux.vnet.ibm.com  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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 12829] kernel complains on ENOSPC

[Theodore Tso]

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

[Bug 12829] kernel complains on ENOSPC

[bugzilla-daemon]

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


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu
         Regression|---                         |No




--- Comment #5 from Theodore Tso <tytso@mit.edu>  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.

[Bug 12829] kernel complains on ENOSPC

[bugzilla-daemon]

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


Eric Sandeen <sandeen@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernie@codewiz.org




--- Comment #6 from Eric Sandeen <sandeen@redhat.com>  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.

[Bug 12829] kernel complains on ENOSPC

[bugzilla-daemon]

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


Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alan@lxorguk.ukuu.org.uk
         Resolution|                            |OBSOLETE




--- Comment #7 from Alan <alan@lxorguk.ukuu.org.uk>  2012-05-30 14:33:32 ---
Closing as obsolete, if this is incorrect please re-open

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

[Bug 12829] kernel complains on ENOSPC

[bugzilla-daemon]

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


Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




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