9 Responses to “Series 5Z … what would you like to know?”

1. Suno Ano Says:
   June 26th, 2009 at 12:11 am

   Hi Neil,

   that link http://www.adaptec.com/en-US/_common/Series5Z/_resources/5Z_faqs.htm?nc=/en-US/_common/Series5Z/_resources/5Z_faqs.htm should be mentioned here I’d say.

2. Neil Says:
   June 26th, 2009 at 1:44 am

   Suno,

   Ok, it’s mentioned
   (Folks, I think this guy is trying to put me out of a job.)

   Ciao
   Neil

3. Ryan Says:
   June 26th, 2009 at 2:47 pm

   Ok, I’ll bite. I took the first challenge and figured out how to get Google results for the last 24 hours. Good to know.

   Read up a bit on the product. Series 5 Raid controller with Flash based cache instead of standard RAM/Battery. I can see the benifits, power and longevity. My impression though was flash is an order of magnitude slower than RAM. Your average flash storage sits somewhere inbetween RAM and the HD in terms of speed. Do you compensate with larger cache size or anything? What type of system is this targeted at?

4. Neil Says:
   June 28th, 2009 at 9:31 pm

   Ryan,

   Good bite. Yes, I too have been taking Google for granted all these years. I wasn’t until I started searching for articles on the 5z to see what our marketing guys had been doing that I realised just searching for “adaptec” brought up some ridiculously old data (aaa-udma raid controllers). Makes me wonder just how many other people are searching, finding answers and not realising just old or disorganised Google is until you do an advanced search.

   Sorry, I digress … now for the answer:

   You say “Flash based cache instead of standard RAM/Battery”. That’s not quite correct. It’s still RAM-based cache, the way we have always done things (at least it’s the same as the series 5 has always been since it’s initial release). In that respect we have not changed the 5 series card.

   The big change is our mentality when the lights go out. With a battery we try to hold on as long as we can (you can all read your own metaphors into that one) … to keep the data in the volatile RAM until the battery dies.

   Our new mentality is to forget about that way of doing things completely. Instead, we copy the data from the volatile RAM into the non-volatile NAND flash memory. Once the data from cache is in the NAND flash we don’t care what happens to the power … at this point we don’t need power to look after the data.

   The SuperCap technology provides enough power for the copy process to take place (in fact plenty) … so basically when we see the lights go out, we quickly copy the cache data to somewhere that doesn’t need power to store the data, then (when we’re finished), we (like the rest of the server) sit around and wait for power to come back on.

   Pretty simple really (that’s easy for me to say but not so easy for the engineers to achieve).

   Hope that clears up some confusion. Then again, did I understand the question correctly?

   Ciao
   Neil

5. Ryan Says:
   July 6th, 2009 at 4:30 am

   Thanks Neil, Thats a great description and it all makes more sense now.

6. Aitor Ibarra Says:
   September 25th, 2009 at 12:52 pm

   Hi,

   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

7. Neil Says:
   September 26th, 2009 at 2:31 am

   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

8. Aitor Ibarra Says:
   September 28th, 2009 at 7:44 am

   Hi 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

9. Neil Says:
   September 29th, 2009 at 7:52 pm

   Aitor,

   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

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

By submitting a comment, you understand that if your post violates any federal, state or local law, or contains libel, slander, defamation, product disparagement, harassment, obscenity, or indecency, it will be edited or deleted.