On Thu, Mar 06, 2014 at 06:54:05PM +0100, Lukáš Czerner wrote: > Yes it tries to align down the start_off of the bigger requests to the 512, > 1024, 2048, or 4096 respectively. What the reason for it is really I have > no idea. The fact is however that this will only affect file systems > with bs smaller than 4k since the start_off will be always aligned to > block size afterwards (obviously). > > That said this alignment is only done when the request is "big > enough". With your change we also do it when the block group is > "small enough" which is the change in behaviour which I think was > not really intended. > > Honestly I do not think this really matters a lot but this alignment > you've added is not necessary. > > All that said, I was getting to rewrite this mess a long time ago, > it's just a reminder that it's something that needs to be done. > Especially since the bigger requests are getting split unnecessarily > which hurts especially in fallocate case. Hey Lukas, where are we with respect to your plans to fix up this code? I'm trying to figure out what we should do with Maurizio's bug fix. Should we apply it even though it's making some changes to the existing behavior. As far as to why the existing code is trying to align the starting offset to a power of two, I believe the idea is to avoid fragmentation, since the normalize_request function will tend to round up allocaiton requests to the same power of two. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
