All good points. Yes, having a massive cache would be nice, but there are many technical aspects that would need to be overcome, with some of those being space on the card, cost of the card once we’d done all this upgrading, speed of transfer of data to NANDflash, size of capacitor required to support this, etc etc.

So yes, a large cache would probably be a great thing but the current card design just won’t support it.

Now what we put on our future cards is totally up to our engineering teams, but I’m sure they are thinking about exactly the same valid points you make here.

Keep an eye on Adaptec’s future releases (not promising anything now )

Ciao
Neil

Thanks for the reply. I wasn’t criticising the size of the flash backup - your reasons sound good to me - but I would like to see more RAM cache, and ideally 8GB or more (and obviously a corrsponding increase in the size of the NAND backup and maybe more capacitor -err - capacity to cover the longer time it would take to destage during a power outage).

I’ve not done enough formal testing to point you at numbers, but I can say a big write cache makes a huge difference. If a write is small enough to fit in the cache, it goes at RAM disk speeds. Random writes complete much faster than hard drive can possibly manage, and even SSDs benefit (especially MLC ones which typically write a lot slower than they read). With just one server and 4GB cache, this covers the vast majority of workloads, but if you use that server as an iSCSI target (as I do) and have a load of VMs accessing it over 10Gbit/E, 4GB can become a bottleneck, and you are back to normal drive speeds. The solution is to add more raid controllers to the target, and/or add more targets, but it would still be great to have a bigger cache. Unfortunately the only ones I know of that go beond 4GB are in SAN arrays like EMC CX4 (which goes to 64GB cache I believe).

Read cache like MaxIQ - I can definitely see the point of that, although in my case I think it would mainly be at startup because beyond that the OS of each VM tends to cache reads in RAM. I think the best overall solution would be a larger RAM cache with NAND backup, then a larger still pool of NAND read/write cache like MaxIQ and then finally whatever drives you have. It would also be really, really helpful if the MaxIQ layer could do some form of block level deduplication, as VMs running their OS drives off the RAID would likely share much of their OS image.

cheers,

Aitor

More does not always equal better. The NAND backup is 4Gb because that module is guaranteed by the memory manufacturers to be around for more than 10 minutes. Smaller modules tend to disappear quickly and we don’t want to redesign half-life because we can’t purchase components.

I’ve not seen any performance comparisons between that particular Areca card and an equal spec 5Z, but I’d be interested if you can point me in the direction of some, because most of the performance comes from algorithms tuned to hardware, not just piles more hardware.

We haven’t gone over 4gb because we don’t believe we need to (for writes that is). Now reads are a totally different matter.

Ciao
Neil

Is there a reason why you’ve stuck with just 512MB of cache (even though the NAND backup is 4GB, right?). You use the same Intel ROC as Areca do on the 1680ix, yet they support 4GB of cache. This does a lot for write performance! I’d like a big cache with flash backup please!

Are ROC’s stuck at 32bit - is that why no-one’s gone beyond 4GB?

Thanks,

Aitor