diff options
author | Theodore Ts'o <tytso@mit.edu> | 2009-12-30 14:20:45 -0500 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2009-12-30 14:20:45 -0500 |
commit | 0637c6f4135f592f094207c7c21e7c0fc5557834 (patch) | |
tree | ee76fc861dffa902e80d0d11c681f5dfa2fcc569 /fs/ext4/bitmap.c | |
parent | 515f41c33a9d44a964264c9511ad2c869af1fac3 (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