SwiftStack's multi-modal 'we're so much better than you' FUD play

If you want a Swift-compliant object storage system, then SwiftStack is the best you you can get. So says, er, Swiftstack itself. The Swift-compliant object storage startup told The Register this when it briefed us on how its open source software was different from, and better than, competing object storage products. …

[CaitlinBestler]

Files are not static

The slickest piece of evasion here is talking about files as though they were the same thing as Objects, just with different metadata attributes.

The fundamental difference is that files are updated very differently than how objects are updated.

Objects are put, as a whole, in a conceptual instant.

Files have a series of writes applied at different offsets, each conceptually at one instant. But there are

complex rules governing when each of those updates can and may be visible to other reading the file.

If you access files as though they were object, which most file access does, then it is easy to map a file to an object. The only difficulties come when you play games like renaming hierarchical directories.

Figuring out exactly how much of the file system semantics to support with objects is a tricky issue. Most end users do not yet fully understand the tradeoffs so it is not surprising that we do not know their preferences yet.

This sort of double-talk from Swiftstack does not help the process.

Promoting placing its clumsy ring on flash is particularly pathetic. It's a data structure that is not needed; its main impact is to delay when the cluster responds permanently to changed membership. Optimizing your achilles heel does not make it a feature.

[Anonymous Coward]

Re: Files are not static

How does Nextenta do it?

[Anonymous Coward]

Re: Files are not static

Yes, I noticed they weren't called out. They've been on my watch list for years. Neat stuff, it's just not something I expect I'll be using for a while, if ever.

[JonASh]

Native support

Doug explains how Swiftstack has native support for Swift while everyone else emulates it. We at Cloudian agree and if your requirements is only for Swift then they are a great choice.

Doug then also states that S3 is the de facto standard and once again we agree. We estimate there are 4,000 apps on S3 and well lets just say not that many for Swift!

Doug then says everyone emulates S3 and here he is wrong. Cloudian uses the S3 spec as our API. We don't emulate S3 it is how we control our system. To use Doug's terminology in the same way that Swiftstack is native for Swift, Cloudian is native for S3. If you believe Doug and Cloudian that S3 is the de facto standard for object then you should be looking at a native implementation ie Cloudian.

All other vendors need a connector or translator to go from S3 the their API. Cloudian does not as it is native S3 and that is why we have full compatibility. We challenge any vendor to come forward and let an independent analyst test our respective API's for S3 compatibility.

[Knieriemen]

Re: Native support

Scratching my head, again. Does anyone at Cloudian do any competitive research before making broad claims like this? The Hitachi HCP also provides native S3 support with full compatibility.

[JonASh]

Response to Knieriemen

Knieriemen - the HCP data sheet on the HDS website states the following " It (HCP) has a powerful native REST-based interface as well as S3 compatible and OpenStack Swift compatible interfaces"

So which is it - native HCP API, native S3 or native Swiftstack? You can't be all 3. Not unreasonably our research assumed your datasheet was correct in which case you have your own HCP API and therefore are not native S3.