ext4: Patch up how we claim metadata blocks for quota purposes
authorTheodore Ts'o <tytso@mit.edu>
Wed, 30 Dec 2009 19:20:45 +0000 (14:20 -0500)
committerTheodore Ts'o <tytso@mit.edu>
Wed, 30 Dec 2009 19:20:45 +0000 (14:20 -0500)
commit0637c6f4135f592f094207c7c21e7c0fc5557834
treeee76fc861dffa902e80d0d11c681f5dfa2fcc569
parent515f41c33a9d44a964264c9511ad2c869af1fac3
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>
fs/ext4/inode.c