More File-System Tests Of The Linux 3.18 Kernel

[sdack]

No ... I also don't believe that it writes 10x times as fast. If you check all graphs you see that btrfs in this system writes 10x as fast for random writes.

So when you do not believe in the huge number differences shown by benchmarks then what exactly is it that reassures you that the smaller differences between kernel versions shown here are an indication of a real regression?! It could well be imaginary.

[stan]

No (to some extend because I use it as my file system for my root drive), at least not with use cases that happen in reality. I also don't believe that it writes 10x times as fast. If you check all graphs you see that btrfs in this system writes 10x as fast for random writes.

http://openbenchmarking.org/result/1411189-LI-FSLINUX3180

That's the reason why I would not look at the absolute values of this test! But the weirdness of this test case / test scenario does not explain why it performance changes between kernel versions.

The huge fail for Btrfs in sequential reads/writes is indeed real, it just doesn't manifest itself noticeably on an average users desktop because normal programs don't just do sequential reads/writes all the time. But it's still a huge problem that Btrfs devs need to fix.

[droste]

So when you do not believe in the huge number differences shown by benchmarks then what exactly is it that reassures you that the smaller differences between kernel versions shown here are an indication of a real regression?! It could well be imaginary.

It may or may not be a real problem, nobody is denying that. Hence this article which mentions a *possible* regression. Now it's time to investigate if this is real issue or not.

The huge fail for Btrfs in sequential reads/writes is indeed real, it just doesn't manifest itself noticeably on an average users desktop because normal programs don't just do sequential reads/writes all the time. But it's still a huge problem that Btrfs devs need to fix.

This is of course possible, I think in a day to day use sequential reads are not that common. Do you know if the writing speed is indeed a lot faster than ext4 for random writes? I can't confirm this here from my normal use.

[stan]

Do you know if the writing speed is indeed a lot faster than ext4 for random writes?

From the benchmark graphs that were linked to (but not included) in this article, it seems that random writes and reads are about equal for Btrfs and ext4:

http://openbenchmarking.org/result/1411196-LI-LINUX318D62

http://openbenchmarking.org/result/1411189-LI-FSLINUX3180

I'd be really happy if the 10x advantage of Btrfs over Ext4 in the Flexible IO random write is actually real.

[coder]

Omg, so terrible results for Btrfs...

Hi, I registered on this site just to point out something about this. When you interpret benchmark results, it's very important that you understand what the benchmark measures, in order to extrapolate the results and predict how they might apply to other usage scenarios.

In this case, the benchmark is measuring unbuffered Posix AIO. This is a fairly esoteric I/O method, and most popular programs that do perform nonblocking file I/O on Linux (which are usually things like web servers, databases, etc.) probably go straight for the Linux-native API. I have firsthand experience with Posix AIO, and I can tell you it's slow and somewhat awkward to use, which probably results in most people going for the much nicer native API.

There's a further consideration, however, which is that async file I/O has been conflated with unbuffered disk I/O (traditionally, in order to use the former, you must use the latter, which is accomplished with the O_DIRECT flag). I don't know if he's changed his tune at all, but Linus is on record as having very low regard for unbuffered I/O and those who use it. Consequently, it's not supported by all filesystems, and even those supporting it probably place low priority on performance. That may help explain why BTRFS scores so much worse.

Finally, keep in mind that it's entirely possible that BTRFS is the only filesystem actually performing unbuffered I/O. What happens if you open a file with O_DIRECT on a filesystem that doesn't support it is that the kernel simply ignores the flag and you get buffered I/O. This could invalidate the results of EXT4 and XFS. I don't know the status of unbuffered I/O support for them, but back when I first dabbled with AIO, EXT4 wasn't yet mainstream and O_DIRECT wasn't supported on XFS.

It would be interesting to see how Linux-native async file I/O compares, although I'd expect to see similar results.