>> http://evilpiepirate.org/git/linux-bcache.git/tree/Documentation/bcache.txt > > no, I was explicitly testing random I/O writes of 4k blocks, > no sequential writing. With a file of 1000 GB it does work, but > if I use a 10000 GB file, it seems to fail. I would expect, that > the size should not really matter here, at least until the cache > is filled up. When the SSD gets too slow it will get by-passed by bcache. The tunable is in the document. Though if memory serves it's a latency of 20ms for writes which is probably way too short since SSDs can easily take 1-5 seconds when they have to resort to heavy lifting. What you should do is turn off RAID controller READ caching entirely. And turn OFF writeBACK-caching for the SSD-based LUN(s) at said controller that are being used as bcache caching devices. It would be helpful is you elaborated as to the HBA and SSD drives you are using. BTW doing RAID across the SSDs being used for cache is rather pointless IMO. You're shortening their life, adding unnecessary write IOPs. It's a cache. It's supposed to fail. Bcache will(?) properly handle a busted SSD. Cache is only useful for absorbing sudden spikes in IOPs or for highly localized and frequently re-used blocks. It's not intended to magically improve the underlying storage by 10-100x under a load that can't be sustained by said layer. Big $$$ SANs have lots of cache but at some point you will reach the saturation point and everything slows to HDD speed. I also wouldn't futz with the EXT4 settings you had posted previously while doing benchmark runs because I expect it gets in the way and makes performance worse than if the block stream was less chunky. Only once you have defined a realistic sustained workload and know how often and how fast journaled-to-SSD writes (bcache write-back) can reasonably be de-staged would I revisit those tuning parameters and see if there is any merit to them. Personally I put NVRAM boards in my servers to be filesystem journals and MD mirror maps. They're incredibly cheap. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
