Ext4-LVM stack Tuning
I suspect that Ext4 could perform much better with even just basic tuning.
In particular the fact that Ext4 on a ZVol outperforms Ext4 on LVM+mdadm is probably because ZFS is auto-tuning every single write in the background.
I do not want to be guilty of my own criticism of many performance test conclusions. Defaults are only a valid "test" if you reason "I don't care how it could perform, only how it performs by default".
I strongly suspect that the mis-match between Write-sizes, Ext4-extend size, LVM allication size and md-raid stripe width is to blame for the bad results seen from the Ext4+LVM stack.
Arguments for testing defaults:
1. Most people don't tune
2. Tuning is too difficult / don't know when to stop tuning
3. Tuning favours one particular workload and is not representative of what other people will experience
4. It should be near-enough to optimal out of the box
5. You need to be a performance expert to do it correctly.
6. Tuning will hurt performance later on when the usage patterns change
My issue with all of this is simple: The conclusions that are made are invalid BECUASE default settings were used for testing. And for no other reason than because the test objective was never properly defined. The conclusion have to follow out of the test objective. The test platform must support evaluating for the objective. The evaluation must have a benchmark for success/failure. Otherwise quite simply you don't know what you are doing.
And then this is all supported by sensationalism. Readers want to get a warm fuzzy feel that they have "the best". So the authors feeding of sensation tend to come to simple conlusions (tm) that A is better than B because A is faster than B.
But they did not test properly ... A is (possibly) only faster than B when tested in that specific way. Faster is not a synonym for better, or else I'd be testing xfs, btrfs, etc.
So put down your test objective (and scope). Write out your expected outcome. Define your test methodology. Design your test platform. Run your tests and record the results. Evaluate your results to check whether they are valid (in particular consider what system resources were the bottlenecks for each test). And then finally make a proper conclusion.
Question: Did I do proper testing above? No, not yet. I have actually just been playing with a test tool (Phoronix test suite) to see how well it supports some of my theories. Ha ha ha. I'll try to do it right when I am on the target platform, probably still some time this week.
I suspect that Ext4 could perform much better with even just basic tuning.
In particular the fact that Ext4 on a ZVol outperforms Ext4 on LVM+mdadm is probably because ZFS is auto-tuning every single write in the background.
I do not want to be guilty of my own criticism of many performance test conclusions. Defaults are only a valid "test" if you reason "I don't care how it could perform, only how it performs by default".
I strongly suspect that the mis-match between Write-sizes, Ext4-extend size, LVM allication size and md-raid stripe width is to blame for the bad results seen from the Ext4+LVM stack.
Arguments for testing defaults:
1. Most people don't tune
2. Tuning is too difficult / don't know when to stop tuning
3. Tuning favours one particular workload and is not representative of what other people will experience
4. It should be near-enough to optimal out of the box
5. You need to be a performance expert to do it correctly.
6. Tuning will hurt performance later on when the usage patterns change
My issue with all of this is simple: The conclusions that are made are invalid BECUASE default settings were used for testing. And for no other reason than because the test objective was never properly defined. The conclusion have to follow out of the test objective. The test platform must support evaluating for the objective. The evaluation must have a benchmark for success/failure. Otherwise quite simply you don't know what you are doing.
And then this is all supported by sensationalism. Readers want to get a warm fuzzy feel that they have "the best". So the authors feeding of sensation tend to come to simple conlusions (tm) that A is better than B because A is faster than B.
But they did not test properly ... A is (possibly) only faster than B when tested in that specific way. Faster is not a synonym for better, or else I'd be testing xfs, btrfs, etc.
So put down your test objective (and scope). Write out your expected outcome. Define your test methodology. Design your test platform. Run your tests and record the results. Evaluate your results to check whether they are valid (in particular consider what system resources were the bottlenecks for each test). And then finally make a proper conclusion.
Question: Did I do proper testing above? No, not yet. I have actually just been playing with a test tool (Phoronix test suite) to see how well it supports some of my theories. Ha ha ha. I'll try to do it right when I am on the target platform, probably still some time this week.
Comment