back to article Seagate's Kinetic drives: They're moving... but in what direction?

It was just 18 months ago that we were all writing about the release of new object-based hard disk drives from Seagate: Kinetic. The idea was that the drives didn’t use traditional storage protocols like SAS and SATA, but instead stored objects written and retrieved over Ethernet. Effectively, each drive is a large key-value …

  1. theOtherJT Silver badge

    I'd love to have an opinion...

    ...but I still can't find anyone whose prepared to sell me just half a dozen or so to do some feasibility testing with.

  2. DJO Silver badge

    Yes, so?

    So it's a network connected file system with multiple redundancies and it's own processing power for housekeeping. It's a fucking file server, perhaps a novel implementation but not exactly a new concept

  3. Anonymous Coward
    Anonymous Coward

    So you pay for the intelligence in each drive

    Instead of saving money on the drives and having the intelligence at the application, OS, or array level. Which is more likely to see feature upgrades, the software on your individual drives (of varying models as you buy over time) or the higher layers?

    Object store drives are a solution looking for a problem, where Seagate's problem is "how do we extract more money from our customers instead of having them give it to someone else?"

  4. Anonymous Coward
    Anonymous Coward

    Maybe it's only me, but I don't see how this scales beyond a single drive. If I spread objects across > 1 drive, I need a mechanism that maps between the object and the drive it resides on. By definition, this mechanism is outside of any single drive. Yet if I have such a mechanism, I arguably have a sizable piece of of the object management logic in hand - why do I need it duplicated in the drive's controller?

    Not to mention redundancy/backup. How do I setup a RAID of these for redundancy and/or performance?

    1. Nate Amsden

      the whole point of this kind of system is you don't use RAID, you replicate the objects.

      But I too am in the camp of this is a "solution in search of a problem".

  5. cloudguy

    Kinetic may have a future...

    Well, when Mr. James Hughes from Seagate publicly demonstrated a Kinetic drive at Basho's conference in San Francisco in October 2013, everyone was suitably impressed with what Mr. Hughes and his team had achieved. Kinetic eliminated the server with its disk controller and POSIX layers. It relied on the Kinetic API and its libraries to use the Kinetic drive as a key/value object store combined with the on-board drive firmware, and dual 1Gb Ethernet interfaces that used the standard SATA/SAS connectors. FYI, the typical HDD has between 1M and 2M lines of code on it.

    Mr. Hughes was on a personal mission to get rid of POSIX and all of the other "busy work" disk drives get involved with when storing data. Kinetic sounded like a breakthrough in data storage and Seagate was making available small-scale test/dev hardware kits so the app/dev crowd could get started. It turned out that the software quality coming from Seagate was not yet production ready.

    Most every object-based storage software vendor made an initial evaluation of Kinetic. Some liked it and planned to develop for it, and some didn't think it offered a significant advantage over what they were already doing. Scality and SwiftStack were on-board with Kinetic. Caringo and Cloudian were not. In 2015 the Linux Foundation started its Kinetic Open Storage Platform with Cleversafe, Scality, Red Hat and Net App numbered among its members. But has Mr. Evans noted, there doesn't appear to be much momentum behind the project almost three years later. The jury is still out on Kinetic, but its prospects may be diminishing as the years go by.

    1. Anonymous Coward
      Anonymous Coward

      Re: Kinetic may have a future...

      As someone who spent some time working with early kinetic drives, what we found was that it was an "almost, but not quite" piece of technology. It provided a nice building block to play with and that was relatively easy to reason about. However, it walked that irksome line of 'smart, but not smart enough'. It forced a lot of complexity up the stack that traditional file systems and object stores abstracted away, and didnt give a really compelling story as to why we should redevelop our stacks to accompany it.

      There was a lot of fanfair and trumpets about removing stack layers, but in practice, it didnt remove them so much as chip away at a few, but add more complexity to others. Again, not necessarily a bad thing, but it was tough to see the value, in some situations (e.g. Kinetic Swift) you could trim down the amount of object storage servers, but you then had some added network complexity and the need to move services like the auditor and replicator elsewhere. We never saw mindblowing performance, and they tended be fairly expensive to cost arguments went out the window too...

  6. razorfishsl

    kiss goodbye to forensics and data recovery.......

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like