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
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....
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.
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
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,
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.
*** Bug 13604 has been marked as a duplicate of this bug. ***
Closing as obsolete, if this is incorrect please re-open