{"push_id":703272621,"size":3,"distinct_size":3,"ref":"refs/heads/master","head":"99b14de42104021f6b7d88118db010d8246bc0c0","before":"218b4e0a7608f7ef37ec72042a68c45e539a5d1c","commits":[{"sha":"bb3250d07ec818587333d7c26116314b3dc8a684","author":{"email":"94939d08528feab90d3eac3ee2d9c0929a8cff04@edechamps.fr","name":"Etienne Dechamps"},"message":"Allocate disk space fairly in the presence of vdevs of unequal size.\n\nThe metaslab allocator device selection algorithm contains a bias\nmechanism whose goal is to achieve roughly equal disk space usage across\nall top-level vdevs.\n\nIt seems that the initial rationale for this code was to allow newly\nadded (empty) vdevs to \"come up to speed\" faster in an attempt to make\nthe pool quickly converge to a steady state where all vdevs are equally\nutilized.\n\nWhile the code seems to work reasonably well for this use case, there\nis another scenario in which this algorithm fails miserably: the case\nwhere top-level vdevs don't have the same sizes (capacities). ZFS\nallows this, and it is a good feature to have, so that users who simply\nwant to build a pool with the disks they happen to have lying around can\ndo so even if the disks have heteregenous sizes.\n\nHere's a script that simulates a pool with two vdevs, with one 4X larger\nthan the other:\n\n    dd if=/dev/zero of=/tmp/d1 bs=1 count=1 seek=134217728\n    dd if=/dev/zero of=/tmp/d2 bs=1 count=1 seek=536870912\n    zpool create testspace /tmp/d1 /tmp/d2\n    dd if=/dev/zero of=/testspace/foobar bs=1M count=256\n    zpool iostat -v testspace\n\nBefore this commit, the script would output the following:\n\n                   capacity\n    pool        alloc   free\n    ----------  -----  -----\n    testspace    252M   375M\n      /tmp/d1    104M  18.5M\n      /tmp/d2    148M   356M\n    ----------  -----  -----\n\nThis demonstrates that the current code handles this situation very\npoorly: d1 shows 85% usage despite the pool itself being only 40% full.\nd1 is quite saturated at this point, and is slowing down the entire pool\ndue to saturation, fragmentation and the like.\n\nIn contrast, here's the result with the code in this commit:\n\n                   capacity\n    pool        alloc   free\n    ----------  -----  -----\n    testspace    252M   375M\n      /tmp/d1   56.7M  66.3M\n      /tmp/d2    195M   309M\n   ----------  -----  ------\n\nThis looks much better. d1 is 46% used, which is close to the overall\npool utilization (40%). The code still doesn't result in perfectly\nbalanced allocation, probably because of the way mg_bias is applied\nwhich does not guarantee perfect accuracy, but this is still much better\nthan before.\n\nSigned-off-by: Etienne Dechamps <etienne@edechamps.fr>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>\nCloses #3389","distinct":true,"url":"https://api.github.com/repos/behlendorf/zfs/commits/bb3250d07ec818587333d7c26116314b3dc8a684"},{"sha":"e8fe6684a5128427e6ad1e75eb548b9fd0c482aa","author":{"email":"94939d08528feab90d3eac3ee2d9c0929a8cff04@edechamps.fr","name":"Etienne Dechamps"},"message":"Document metaslab_aliquot.\n\nSigned-off-by: Etienne Dechamps <etienne@edechamps.fr>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","distinct":true,"url":"https://api.github.com/repos/behlendorf/zfs/commits/e8fe6684a5128427e6ad1e75eb548b9fd0c482aa"},{"sha":"99b14de42104021f6b7d88118db010d8246bc0c0","author":{"email":"94939d08528feab90d3eac3ee2d9c0929a8cff04@edechamps.fr","name":"Etienne Dechamps"},"message":"Make metaslab_aliquot a module parameter.\n\nThis seems generally useful. metaslab_aliquot is the ZFS allocation\ngranularity, which is roughly equivalent to what is called the stripe\nsize in traditional RAID arrays. It seems relevant to performance\ntuning.\n\nSigned-off-by: Etienne Dechamps <etienne@edechamps.fr>\nSigned-off-by: Brian Behlendorf <behlendorf1@llnl.gov>","distinct":true,"url":"https://api.github.com/repos/behlendorf/zfs/commits/99b14de42104021f6b7d88118db010d8246bc0c0"}]}