summaryrefslogtreecommitdiff
path: root/fs/ext4/bitmap.c
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2009-12-30 14:20:45 -0500
committerTheodore Ts'o <tytso@mit.edu>2009-12-30 14:20:45 -0500
commit0637c6f4135f592f094207c7c21e7c0fc5557834 (patch)
treeee76fc861dffa902e80d0d11c681f5dfa2fcc569 /fs/ext4/bitmap.c
parent515f41c33a9d44a964264c9511ad2c869af1fac3 (diff)
ext4: Patch up how we claim metadata blocks for quota purposes
As reported in Kernel Bugzilla #14936, commit d21cd8f triggered a BUG in the function ext4_da_update_reserve_space() found in fs/ext4/inode.c. The root cause of this BUG() was caused by the fact that ext4_calc_metadata_amount() can severely over-estimate how many metadata blocks will be needed, especially when using direct block-mapped files. In addition, it can also badly *under* estimate how much space is needed, since ext4_calc_metadata_amount() assumes that the blocks are contiguous, and this is not always true. If the application is writing blocks to a sparse file, the number of metadata blocks necessary can be severly underestimated by the functions ext4_da_reserve_space(), ext4_da_update_reserve_space() and ext4_da_release_space(). This was the cause of the dq_claim_space reports found on kerneloops.org. Unfortunately, doing this right means that we need to massively over-estimate the amount of free space needed. So in some cases we may need to force the inode to be written to disk asynchronously in to avoid spurious quota failures. http://bugzilla.kernel.org/show_bug.cgi?id=14936 Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/bitmap.c')
0 files changed, 0 insertions, 0 deletions