<   Previous Post  Over-allocation vs...
My blog URL is chang...  Next Post:   >

Comments (8)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Permalink

FYI... Falconstor is pretty comparable with SVC, I would not lump them in with Datacore.<div>&nbsp;</div> I like SVC better, especially the ability to scale to 8 nodes vs Falconstor's 2...but really to give Falconstor their due, some corrections I think you need to make are:<div>&nbsp;</div> 1) It does do caching like SVC using mirror ram between appliance nodes. It can also use a pool SSD to do some automatic migrations of hot data which is kind of cool.<div>&nbsp;</div> 2) Datacore uses Windows (ug), and runs on Linux or Solaris...they have implemented using custom kernel modules, and drivers so they do have raw low level access to the hardware....I would guess that you might be correct about datacore not since its running on a closed source platform.<div>&nbsp;</div> Now...where is that thin provisioning for SVC? Its the only thing that even got us to look at Falconstor vs SVC. :)<div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>

2 localhost commented Permalink

&gt;Datacore uses Windows (ug), and runs on Linux or Solaris<div>&nbsp;</div> Opps.. should have said "and Falconstor runs on Linux or Solaris" there.

3 localhost commented Permalink

Thanks "Han" I have removed Falconstor as appropriate.<div>&nbsp;</div> As for Thin provisioning, contact your sales representative, I am not at liberty to comment on roadmap plans I'm afraid :)

4 localhost commented Permalink

With a second layer of cache between my host and my storage controller, don't I risk data loss or corruption if one of my storage arrays loses power but the SVC does not? The scenario I'm thinking of would go like this: A host sends a write to disk, SVC acknowledges the write, and has yet to de-stage some number of additional writes to the back end array. For whatever reason, power is cut to the array. Since it's on battery power, the array stops accepting IO and de-stages its own writes to disk before everything powers off.<div>&nbsp;</div> What happens to those stranded writes in the SVC cache? Does SVC just pitch them? Or are they statically stored in cache until the array comes back up at which point they're sent again?

5 localhost commented Permalink

"We even provide a ‘cookbook’ that details how to interpret the raw data for users to build their own scripts or tools to monitor their systems if they do not have TPC."<div>&nbsp;</div> Please can you give us a link or something to this cookbook.We are using TPC, but sometime it can be handy to have some `workarounds´<div>&nbsp;</div> TIA Tmasteen

6 localhost commented Permalink

Hi, here's the link that describes what all the xml attributes mean, its a case of either decoding from the XML into something useful (internally we decode into a database for subsequent extraction/searching etc) or scripting some grep, sed / awk to extract and generate some .csv files. <div>&nbsp;</div> http://www-1.ibm.com/support/docview.wss?rs=591&amp;context=STPVGU&amp;context=STPVFV&amp;q1=statistics&amp;uid=ssg1S1003036&amp;loc=en_US&amp;cs=utf-8&amp;lang=en<div>&nbsp;</div> (Split URL into two lines for readability)

7 localhost commented Trackback

Hi Barry,<div>&nbsp;</div> I love this series, and I hope you don't mind if I ask hard questions- I do it because I love you ;)<div>&nbsp;</div> "There is also evidence to show that even enterprise controllers with large caches are not impacted adversely by SVC, as the actual read or write operations will generally 'hit' the cache in the controller just as they would do without SVC fronting them."<div>&nbsp;</div> Firstly, evidence to show that SVC doesn't hamper high end controllers' performance is not a selling point. SVC seems more popular with companies who have mid range devices because of this, I expect :)<div>&nbsp;</div> Secondly, your DS8000 has something called "adaptive replacement cache" technology- I was very impressed when it was described to me as an sophisticated algorithm that was developed to better predict random reads, but you have told me in another post that SVC does not contain this algorithm. Wouldn't SVC negate the value of this feature if all caching is performed in the SVC appliance?

8 localhost commented Permalink

OSG, glad you like the series. Easy questions are boring! Its the hard ones we live for! :)<div>&nbsp;</div> So my comment about 'evidence' was aimed more at our EMC friends who try to claim that SVC negates caching effects in downstream controllers. More and more DS8000's are being sold with SVC fronting them and we do have a lot of DMX customers out there.<div>&nbsp;</div> Your second point about 'different' algorithms in the underlying storage controllers. If you think about it, if an algorithm in an underlying controller does predict a prestage and gets it into its cache. If SVC does not have the same predictive algorithm then it would see the IO as a miss and send it on to the controller, where it IS a hit, thus you still get the benefit of the underlying controller algorithm with only the additional tens of microseconds that SVC adds. Overall say 1-3ms depending on the fabric speed. Overall compared to an underlying controller that does not have the same predictive algorithm, which may take 10+ms to get the data from disk, you are going to see the benefits of the controller cache algorithms. <div>&nbsp;</div> The cache algorithms in SVC came out of the IBM Almaden labs, as did the general architecture of SVC as I explained in a previous post. There are some nifty 'heat and effectiveness' algorithms in the pre-stage area and these do also happen all the time, not just under detected sequential workloads. <div>&nbsp;</div> The code is also following an evolutionary process and as performance architect I'm constantly analysing the cache behaviour at a low level and suggesting tweaks and fine tuning (based on measured and observed characteristics of low end as well as high end systems) I'm investigating some interesting algorithms at the moment that should boost performance even further.<div>&nbsp;</div> One of the greatest attributes of SVC is the continual code and feature enhancements that are supported not only on the latest and greatest hardware base, but also all previous node hardware. Such code tuning and cache algorithm enhancement can lead to substantial gains for existing customers meaning they don't need to upgrade their hardware just yet. The 4.2.0 code stream for example added between 10 and 30% to the existing hardware platforms as was discussed in detail in the SVC 4.2.0 Performance White Paper written by myself and Bruce McNutt in Tucson.