Hi Ted, On 04/30/2015 07:57 AM, Theodore Ts'o wrote: > This is one of the reasons why I find head-to-head "competitions" > between file systems to be not very helpful for anything other than > benchmarketing. It's almost certain that the benchmark won't be > "fair" in some way, and it doesn't really matter whether the person > doing the benchmark was doing it with malice aforethought, or was just > incompetent and didn't understand the issues --- or did understand the > issues and didn't really care, because what they _really_ wanted to do > was to market their file system.
Your proposition, as I understand it, is that nobody should ever do benchmarks because any benchmark must be one of: 1) malicious; 2) incompetent; or 3) careless. When in fact, a benchmark may be perfectly honest, competently done, and informative. > And even if the benchmark is fair, it might not match up with the end > user's hardware, or their use case. There will always be some use > case where file system A is better than file system B, for pretty much > any file system. Don't get me wrong --- I will do comparisons between > file systems, but only so I can figure out ways of making _my_ file > system better. And more often than not, it's comparisons of the same > file system before and after adding some new feature which is the most > interesting. I cordially invite you to replicate our fsync benchmarks, or invent your own. I am confident that you will find that the numbers are accurate, that the test cases were well chosen, that the results are informative, and that there is no sleight of hand. As for whether or not people should "market" their filesystems as you put it, that is easy for you to disparage when you are the incumbant. If we don't tell people what is great about Tux3 then how will they ever find out? Sure, it might be "advertising", but the important question is, is it _truthful_ advertising? Surely you remember how Linus got started... that was really blatant, and I am glad he did it. >> That are the allocation groups. I always wondered how it can be beneficial >> to spread the allocations onto 4 areas of one partition on expensive seek >> media. Now that makes better sense for me. I always had the gut impression >> that XFS may not be the fastest in all cases, but it is one of the >> filesystem with the most consistent performance over time, but never was >> able to fully explain why that is. > > Yep, pretty much all of the traditional update-in-place file systems > since the BSD FFS have done this, and for the same reason. For COW > file systems which are are constantly moving data and metadata blocks > around, they will need different strategies for trying to avoid the > free space fragmentation problem as the file system ages. Right, different problems, but I have a pretty good idea how to go about it now. I made a failed attempt a while back and learned a lot, my mistake was to try to give every object a fixed home position based on where it was first written and the result was worse for both read and write. Now the interesting thing is, naive linear allocation is great for both read and read, so my effort now is directed towards ways of doing naive linear allocation but choosing carefully which order we do the allocation in. I will keep you posted on how that progresses of course. Anyway, how did we get onto allocation? I thought my post was about fsync, and after all, you are the guest of honor. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
