FalconStor struggles on as antsy backers whine 'C'mon, let's sell' After losing its CEO a few weeks ago, standalone storage software shipper FalconStor has duly reported poor results. Since then it has got into bed with a new VC to shore up its balance sheet, ended an investment banking deal with Wells Fargo, and teamed up with Violin Memory to develop new products. The interim president and …
SSD is high IO performance storage device. FalconStor products are feature rich storage appliance and they have some very nice features pertain to data protection and recovery, however, their IO performance is not impressive that can barely beat a couple of SSD let alone an array of SSD. Violin already has an insanely high IO performance (1 Million IOPS as claimed on the web) flash memory array, that's many many times faster than FalconStor appliance. Who on earth would want an FalconStor appliance to drive much high-speed Violin array unless FalconStor people re-engineer their architecture? Just no idea where the minds of Violin's executives are heading to. Why not just acquire FalconStor and merge their nice features into your high performance SSD array controller, isn't that a no-brainer?
hfhghg6767, Isn't "Latency" or "IOPS" the same thing? If you can achieve low IO latency you get high IOPS (the amount of IO successfully processed per second). Or am I missing something here? Using FalconStor appliance as an frontend controller and Violin memory as backend storage will not work. The latency bottleneck is not in Violin box, not between Falcon and Violin, but inside Falcon box. I'm skeptical how this deal gonna work out unless Falcon people make a design change to their product. Well, if this deal forces FalconStor to drastically improve their product, i'd actually feel happy for them because they're willing to do something right finally after wasting three year time doing nothing but shooting the stock down into pink sheet candidate. It's just the timing is not on their side now. We'll see.
No, it's not quite the same thing. Latency is about the time delay experienced in a system, iops is about input/output operations per second. Latency will of course affect iops, but iops is a much more comprehensive figure, influenced by among other things, the balance of read and write operations, the mix of sequential and random access patterns, the number of worker threads and queue depth, as well as the data block sizes.
Violin is _all about the latency_ and putting an FS box in between, will add a negligible amount of microseconds in latency to the violin box, which won't affect 99.9% of the violin customer, while at the same time, providing the violin box with comprehensive data protection features.
Another example, I might not need 1000000 IOPS, since I have a small db, but my db must respond to the few requests it gets with lightning speed. In that scenario, latency is important, but not handling millions of requests at the same time.
I don't disagree with what you talk about the difference between Latency and IOPS but I think in this Violin deal IOPS (and the IO latency cost inside Falcon box) is the most critical part.
I fully disagree with your statement about Falcon box only adding a negligible amount of microseconds in latency. Let's say this "negligible latency" is one or two microseconds, that should give Falcon box about half-million to one-million IOPS. If you ever used a Falcon box, you tell me what is the actual IOPS out of their box, it is a much much lower number. Their box is just a Linux appliance and their software can just do this much no matter how many host ports you install there.
That being said, the latency inside Falcon box is not negligible. Sure, this latency is still negligible for the small db you talked about but it limits the overall IOPS performance as a storage IO controller because Falcon box is supposed to service many many host IO not just a few. If the IOPS is not able to go inline with what Violin can offer then what is the point to add it in between hosts and Violin storage. Put it this way, if many host IO already consume up the limited IOPS from Falcon box, and now you add a new host that running a small db like you talked about, then what do you expect?
Engineer a high IOPS for Falcon box that is inline with Violin box is what the most needed, everything else is nothing.
Good discussion here. =) I think I see where you're coming from. I agree that adding something "in the middle" is not the correct choice in high IOPS environments, but that goes for all storage virtualization. The virtualization should be added because you value the increased flexibility, or, the added data protection features that violin does not have.
I still stand firm in my belief that violin + fs, could be (and is) a good choice in smaller environments, or in a subset of big environments, where extreme low latency is required, but at the same time I agree with you, that it is wrong to add FS + violin or any other box in between, in high iops environments on a large scale.
Let's see what fs does. If they will add a high iops box, or as now, let it be and be content with addressing smaller environments.
Thank you for a good discussion. =)
I think I over-stressed the necessity of high IOPS requirement and begin to understand what you talked about. FalconStor is able to leverage their existing data protection features by working with Violin, and that not only can drastically improve the performance for their existing shops but at the same time becomes much more competitive in the small/medium markets they feel comfortable with. I think you made an fair and excellent point.
I would still love to see FalconStor and Violin both working together to penetrate high-end market but that is the part that leaves a lot to be desired.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
