This is my first attempt to fix the ext4_mb_normalize_request() function in in ext4 which deals with file preallocations. This is not yet a final version as it needs more testing, however I'd like to see some suggestions. Currently there are couple of problems with ext4_mb_normalize_request(). - We're trying to normalize unwritten extents allocation which is entirely unnecessary, because user exactly knows what how much space he is going to need - no need for file system to do preallocations. - ext4_mb_normalize_request() unnecessarily divides bigger allocation requests to small ones (8MB). I believe that this is a bug rather than design. - For smaller allocations (or smaller files) we do not even respect the fe_logical. Although we do respect it for bigger files. - Overall the logic within ext4_mb_normalize_request() is weird and no-one really understand why it is the way it is. Fix all of this by: - Disabling preallocation for unwritten extent allocation. However because the maximum size of the unwritten extent is one block smaller than written, in order to avoid unnecessary fragmentation we limit the request to EXT_INIT_MAX_LEN / 2 - Get rid of the "if table" in ext4_mb_normalize_request() and replace it with simply aligning the assumed end of the file up to power of two. But we still limit the allocation size to EXT4_BLOCKS_PER_GROUP. Also do this on file system block units to take into account different block sized file systems. It passes xfstests cleanly in default configuration, I've not tried any non-default options yet. I've tried to test how much it changes allocation. The test and some results can be found at http://people.redhat.com/lczerner/mballoc/ normalize.sh is the simple script I run and output.normalize_orig[34] contains result from the vanila 3.15.0 while output.normalize_patch[56] contains results with this patch. >From the performance stand point I do not see any major differences except that untar seems to always generate better results (which might be because of bigger continuous extents). Free space fragmentation seems to be about the same, however with the patch there seems to be less smaller free space extents and more bigger ones which is expected due to bigger preallocations (and I think it's a good thing). The biggest difference which is obvious from the results is that extent tree is much smaller (sometimes five times smaller) with the patch. Except of the fallocate case because we now limit the requests to (EXT_INIT_MAX_LEN / 2) so we can not merge them - it might be worth experimenting with something smaller which is a factor of unwritten extent size. But as I said the extent tree is much smaller which means that the extents overall are bigger which again is a good thing. This becomes very obvious when we look at the extent tree of the image file (the last steps in the test). What do you think ? Thanks! -Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
