Bug 12829
Summary: | kernel complains on ENOSPC | ||
---|---|---|---|
Product: | File System | Reporter: | Eric Sandeen (sandeen) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | CLOSED OBSOLETE | ||
Severity: | normal | CC: | alan, bernie, harish.lkd, MadLoisae, tytso |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.29-rc6 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Eric Sandeen
2009-03-06 14:33:05 UTC
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 |