Hacker News new | past | comments | ask | show | jobs | submit login

They are saying the paper they want arms and platters as it's more economical. An HDD is cheaper than an SSD of the same capacity at four to ten times and I don't think the electricity cost will offset this if you care more about capacity than performance.



It is right now, but silicon and precision mechanics scale with different curves. There is a point where spinning metal will no longer be viable as a competitor and I'll guess, based on a hunch, it's not that far into the future.


Flash is not getting cheaper faster than HDD's, once you control for write endurance. One of the big messages in the paper is that IOPS matter. If you only have a petabyte or two of data, you can use a brute force solution such as flash or 15k drives. But at Cloud scale (we used to say Google scale, but there other companies like Amazon and Microsoft and Facebook that run at these scales now) you just can't afford that much flash.

So the trick is to use every last IOPS that you can out of each and every disk, and that means provisioning and spreading out your data across an entire fleet of disks. The alternative, where you silo your storage in disk pools, and where some disks or disk pools have IOPS that are unused --- wasted, and where you make up for that by using flash for your hot and warm workloads is just a much more expensive way to do things.

It's for that reason that SMR drives aren't all that interesting. Sure, you get 20% more capacity, but at the cost of burning most of your IOPS for GC. Or if you move all of your SMR-friendly data to the SMR drives, that's cold data, and it means that you've wasted all of the IOPS that those SMR drives are capable of. Which means the rest of your disk fleet is now much hotter, and you might have to buy more CMR spindles to cover the cost --- at which point the cost advantage of SMR drives disappears.

(I helped to author the section about SMR drives, and why we are interested in hybrid SMR/CMR drives as a solution to this problem; read the paper for more details.)


If you get any response from disk vendors I'd be very interested to hear about it and be somehow involved. I've been asking them similar things for some time and got no response beyond a "we'll take a look" and never getting a reply back.

One such request that is also mentioned in your article is to get more granular responses in the IO responses, in a SAS disk you can get correctable errors that do not hamper the behavior but will get you information on the internal status and actions of the disks. SATA has a problem with this since any IO Error in SATA will cancel all outstanding IOs. Though I think that there are device logs and such now that can be implemented to provide some semblance of a similar result.


  > Flash is not getting cheaper faster than HDD's, once you control for write endurance.
Is the category of WORM-suitable data (like videos) not large enough to be interesting, or is there simply no WORM technology better than writable?


There's no WORM technology better than rewritable as far as I'm aware. Storage density is already well above the point where optical technologies are viable.


I think the question is why does P/E cycle count matter for storing YouTube videos? As videos are uploaded, you shard them with FEC across your SSD array, but once the blocks are written, when would you ever need to erase them? The only concern is longevity of a single block which requires some amount of P/E (re-charging the cell) but lets say that's just 1 full disk write per month to keep everything fresh...


OK. I was thinking more along the lines of PROM (i.e. random access) but I can imagine there's nothing now more useful than flash.


There is "antifuse", although it's a little slow to program. Commonly available on chips in small amounts for secure key storage, serial numbers, calibration etc.

I'm not aware of anyone selling standalone parts, but here is an IEEE paper: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124097... (512Mb in 2003!)

If Google really wanted to, they could make a couple of petabytes of slow-to-write memory by commissioning it themselves for low numbers of millions of dollars. But I suspect they value the rewritability.

See also http://www.eetimes.com/document.asp?doc_id=1328234




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: