HDD/SSD Performance With MDADM RAID, BCache On Linux 4.14

[phoronix]

Phoronix: HDD/SSD Performance With MDADM RAID, BCache On Linux 4.14

It's been one year since last testing BCache as a means in the Linux kernel's block layer to allow an SSD to serve as a cache for a larger but slower rotational hard drive. So I have carried out some fresh benchmarks using the Linux 4.14 Git kernel to provide not only fresh benchmarks of BCache but also MDADM SSD RAID on Linux and some other fresh SSD/HDD benchmarks.

http://www.phoronix.com/vr.php?view=25262

[boxie]

so, bcache - still not worth it (at least for these use cases)

I would have honestly thought that bcache writeback would have been quicker. Michael any chance of you adding zfs with its zil/slog ssd options?

[torsionbar28]

I found this a rather odd statement, from the first graph:

"Using the BCache writeback mode where data is written to the SSD and then asynchronously to the HDD still leaves a significant performance drop compared to using a single SATA 3.0 SSD."

The graph clearly shows BCache provides a significant performance improvement over HDD alone, at least in this one test. Which is exactly what the mission of BCache is. Yes an SSD cache in front of an HDD is always going to be slower than a pure SSD storage environment - obvious statement is obvious. The point is it gives a nice performance boost to a mechanical HDD, so it was an odd choice of words failing to acknowledge this success.

[boxie]

The graph clearly shows BCache provides a significant performance improvement over HDD alone

and some others too. surely though it should be more performant (with the caveat that I know nothing about how it is implemented)

[duby229]

Well, in a lot of those benches bcache's writeback mode was actually slower than the single HDD. It seems weird.

[Think]

If there is sufficient interest I will repeat the tests with XFS and (native RAID) Btrfs in a future article.

Talking about comparisons, ZFS would be interesting as well.

[uentity]

I think it would be interesting to test one more option of having external EXT4 journal on SSD. And how it performs with various journal size.

[uentity]

I think it would be interesting to test one more option of having external EXT4 journal on SSD. And how it performs depending on journal size.

[phred14]

I think it would be interesting to test one more option of having external EXT4 journal on SSD. And how it performs with various journal size.

I remember reading about a year or so ago - somewhere, I forget where - that using SSD as the external journal for ext4 on a spinning disk gave much better performance than bcache. It would be interesting to see how this affects the lifetime of the SSD, since this puts it into a write-heavy situation. It might also be interesting to split the SSD, using some for external journal and some for writearound-mode bcache to help reads.

[Guest]

Michael, these benchmarks are really useless for average laptop/desktop users. Because, desktop/laptop users don't need HDD performance, but fast reactions, while performing task, which operate repeatedly on small amount of data (<60 GB). All remaining data are mostly archives of old projects, which aren't opened for long time, videos, photos, documents, and so on,...

I'm thinking about 1TB HDD + 128GB SSD cache setup for laptop usage. I only need to start computer fast, to open applications fast, and to build small projects quickly. Most of these operations are based on reads of many small files (source files, application binaries, OS libraries and startup). And, the complete use-case won't overcome 60GB of read data over a week, and 1GB of new data (well, if I don't count temporary files, which get repeatedly removed).

For this usage the bcache (writeback mode) should eliminate problem of seek times with HDD. Isn't it?

Could you just benchmark common tasks? For example, times of following actions: repeated computer startup, repeated IDE startup, repeated clean+rebuild of a regular sized project (not millions LoC kernel),...