]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
ext4: Calculate metadata requirements more accurately
authorTheodore Ts'o <tytso@mit.edu>
Mon, 31 May 2010 02:49:23 +0000 (22:49 -0400)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 2 Aug 2010 17:21:12 +0000 (10:21 -0700)
commitc9b832385f007ceac33b7515f24f2f2dcfd9c2ce
treebdbe865affbb2f56bd6e59a8276f719fc1143ec1
parent5d11fc79a018ac6f347b6e8cc39d8dc5c52bb064
ext4: Calculate metadata requirements more accurately

commit 9d0be50230b333005635967f7ecd4897dbfd181b upstream (as of v2.6.33-rc3)

In the past, ext4_calc_metadata_amount(), and its sub-functions
ext4_ext_calc_metadata_amount() and ext4_indirect_calc_metadata_amount()
badly over-estimated the number of metadata blocks that might be
required for delayed allocation blocks.  This didn't matter as much
when functions which managed the reserved metadata blocks were more
aggressive about dropping reserved metadata blocks as delayed
allocation blocks were written, but unfortunately they were too
aggressive.  This was fixed in commit 0637c6f, but as a result the
over-estimation by ext4_calc_metadata_amount() would lead to reserving
2-3 times the number of pending delayed allocation blocks as
potentially required metadata blocks.  So if there are 1 megabytes of
blocks which have been not yet been allocation, up to 3 megabytes of
space would get reserved out of the user's quota and from the file
system free space pool until all of the inode's data blocks have been
allocated.

This commit addresses this problem by much more accurately estimating
the number of metadata blocks that will be required.  It will still
somewhat over-estimate the number of blocks needed, since it must make
a worst case estimate not knowing which physical blocks will be
needed, but it is much more accurate than before.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/ext4/ext4.h
fs/ext4/ext4_extents.h
fs/ext4/extents.c
fs/ext4/inode.c
fs/ext4/super.c