On Fri, Dec 21, 2012 at 02:25:26AM +0100, Jan Kara wrote: > Am I missing something Dmitry? Also I was wondering about one thing: Does > anybody see a problem with disabling merging of uninitialized extents > completely? It would simplify the code (end_io conversion doesn't need to > potentially split extents) and the case when we really want to merge > extents - i.e., when someone calls fallocate() on small chunks - doesn't > seem like the case we need to optimize for? Which case specifically are you talking about here? Are you talking about the merging of _formerly_ uninitialized extents? i.e., what keeps the extent tree from exploding if you fallocate one megabyte region, and then write to all 256 blocks of that one megabyte region, except in a random order? Or something else? > Also it would bound the amount of transaction credits we need for > conversion to 1 block which would make it easier for me to change > ext4 to clear PageWriteback only after extent conversion is done > (again code simplification, more uniform handling of page > writeback). So I'm confused. If it's the case that we're thinking about, we only need a single transaction credit, because we're not currently merging across adjacent interior extent tree blocks. Can you be a bit more explicit about which case you're thinking about? I do agree that the extent tree code is too complicated, but we also have the problem that we probably been more merging, not less, since we can already end up with a case where you start with a single extent tree block after fallocating a gigabyte or two. Then after writing randomly into that gigabyte file using AIO, we can end up with a very deep, spindly extent tree containing multiple interior extent tree blocks, because we're not doing sufficient merging --- and in particular, we currently have no way at all of decreasing the depth of the extent tree. - Ted -- 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
