On 10/31/2011 06:15 PM, Theodore Tso wrote: > > On Oct 27, 2011, at 11:31 PM, Tao Ma wrote: > >> Forget to say, if we increase the extent length to be cluster, there are >> also a good side effect. ;) Current bigalloc has a severe performance >> regression in the following test case: >> mount -t ext4 /dev/sdb1 /mnt/ext4 >> cp linux-3.0.tar.gz /mnt/ext4 >> cd /mnt/ext4 >> tar zxvf linux-3.0.tar.gz >> umount /mnt/ext4 > > I've been traveling, so I haven't had a chance to test this, but it makes no sense that changing the encoding fro the extent length would change the performance of the forced writeback caused by amount. There may be a performance bug that we should fix, or may have been fixed by accident with the extent encoding change. > > Have you investigated why this got better when you changed the meaning of the extent length field? It makes no sense that such a format change would have such an impact…. OK, so let me explain why the big cluster length works. In the new bigalloc case if chunk size=64k, and with the linux-3.0 source, every file will be allocated a chunk, but they aren't contiguous if we only write the 1st 4k bytes. In this case, writeback and the block layer below can't merge all the requests sent by ext4. And in our test case, the total io will be around 20000. While with the cluster size, we have to zero the whole cluster. From the upper point of view. we have to write more bytes. But from the block layer, the write is contiguous and it can merge them to be a big one. In our test, it will only do around 2000 ios. So it helps the test case. Thanks Tao -- 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
