Comprehensive data protection for all workloads
Post Reply
davow
Influencer
Posts: 22
Liked: 2 times
Joined: Jan 25, 2013 5:05 pm
Full Name: D W
Contact:

Linux SSD (or RAM) caching for storage file merges

Post by davow »

Hi,
Is anybody using any of the block caching solutions in Linux successfully for Veeam storage server specifically for helping out with IO on file merges on slower large storage SATA drives?
eg EnhanceIO, RapidCache, Flashcache, bcache..etc or even LSI Cachecade (or whetever its called)

Due to the random IO nature of file merges, I thought an SSD or ram cache may help although I accept it would be hard to get the "cached" data into smaller SSD ppol of storage space for it to be worthwhile. I thought it could help out with writes though if using writeback mode.

Is this achievable? Will the IO pattern make use of a caching layer in front or just bypass it?

I'm currently using 14 x 4TB WD RED EFRX in a Btrfs RAID 10 formation and want to try increase the performance where possible. (Yes, yes, I know get better magnetic drives. Let's take that out of the equation for this question though as it would still apply if I had 15k or 10k disks.)

Why BTRfs? Built-in volume manager, checksums + all the benchmarks I see show it is near enough to ext4/xfs in Random IO and better in some cases. (I have no RAID card).
dellock6
VeeaMVP
Posts: 6139
Liked: 1932 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Linux SSD (or RAM) caching for storage file merges

Post by dellock6 »

Hi,
I'm looking too these weeks at EnhanceIO as a viable caching system for linux repositories. By reading around sounds like a better solution than others for the specific use case here, for example bcache seems faster but has no power loss protection and in a write-back cache used for a repository, I would go for a "slower" solution like enhanceIO that is safer...
That said, I didn't tested it yet but surely the cache can help, in what percentage depends on the effectiveness of the cache itself and how much blocks it can capture when dealing with Veeam merge operations. It's indeed interesting to test it, and I agree with you the difference in performances between SSDs and "any" kind of magnetic drives (even the 15k) justifies its usage.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
davow
Influencer
Posts: 22
Liked: 2 times
Joined: Jan 25, 2013 5:05 pm
Full Name: D W
Contact:

Re: Linux SSD (or RAM) caching for storage file merges

Post by davow »

Thanks Luca. I'm only using a mirrored set of 120 GB Crucial MX500 drives at the moment with EnhanceIO. Stats indicate I get some hits but mainly < 10 %. Interestingly, my io_hist file indicates the majority of blocks are 64k yet I created an 8k blocksize. I am going to rebuild a new cache with a 64k blocksize and also order some 480GB Enterprise-y level SSD such a Intel s3500 or Samsung SM843t.

I'll update this post in the future for anyone interested.

FYI. For people not familiar with the caching software alternatives, EnhanceIO allows the cache to by dynamically added and removed on an existing block device...hence my preference for it.

UPDATE: Cannot create 64k blocksize in EnhanceIO. 2k,4k, and 8k re the only options.
dellock6
VeeaMVP
Posts: 6139
Liked: 1932 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Linux SSD (or RAM) caching for storage file merges

Post by dellock6 »

Thanks! Indeed let's keep this thread alive as much as possible.
For the intel SSDs, if you can spend a little more, I'd go for the 3700, they have better write performances while the 3500 were mainly designed for reads. I think that at least for backup operations (not the merge ones) this wil help, as the cache can receive and commit back the writes arriving from proxies and then flush to the disks.
I'd go for these tests before trying out the merge operations, since these are often unique blocks and most of all they are only read once from the incremental and write once in the full file, there's little a cache can do with a non-repeated I/O operation.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Post Reply

Who is online

Users browsing this forum: No registered users and 125 guests