[baruch]

They do a different tradeoff here. There is no need for a hardware raid if performance is not your main concern (and even if it is hardware raid is no panacea), if they save everything to disk before acknowledging it they don't need a battery and I'm not sure what you refer to as cap.

Their hardware design is specifically geared towards their use-case and I applaud them for knowing how to optimize for their use-case. I wouldn't use it for mine but only because it's not a good fit.

They can open-source the hardware because the real secret sauce is the software and the hardware open sourcing gives them a nice edge in marketing.

[dmourati]

cap=capacitor. http://www.lsi.com/downloads/Public/MegaRAID%20SAS/MegaRAID%...

Edited to add: They've optimized for hardware purchase price and given up reliability (HW RAID, battery, cap), performance, and maintainability. The strange thing is the overall cost of the storage system is driven by power, not purchase price. Smarter RAID controllers, like I link above, let you manage power by spinning down disks as they are unused and thereby reducing your power draw. Can't do that with SW RAID that I've ever seen. Take a look at Amazon Glacier which I suspect is using this power-off strategy to drastically reduce their costs.

[baruch]

Their use case is mostly write-once, they fill the data and never delete. The write-rate is probably more limited by the upload speeds of its users than the disk bandwidth and the multitude of port-multipliers that they use. Recovery is anyway mostly about copying all the user data to an external HDD and ship that which is a lot less performance critical as shipping the HDD will take a lot longer than reading all the data from across their systems.

As for saving power by spinning down disks, it is likely to be useful to them and is completely possible even in SW RAID though it requires some managing to perform effectively.

There isn't much that is applicable directly to most other use-cases but if your data is mostly sitting idle and you only need occasional access to it the backblaze pod is a nice design. If you care about performance and do not deploy multiple pods with redundancy between them you are not likely to be happy with the result.

[morganw]

> Recovery is anyway mostly about copying all the user data to an external HDD and ship that which is a lot less performance critical as shipping the HDD will take a lot longer than reading all the data from across their systems.

I've restored just a few files from Backblaze. While it's an "offline" operation where you choose the file, then get a notification when it's ready to be downloaded, it took only a handful of minutes.

It's not why I signed up with them, but it was delightful that it worked.

[secabeen]

Actually, Glacier is probably backed mostly by tape with a disk cache. Writing then becomes cheap, as you can grab the next blank tape, but restores take a while, as they have to pull the specific tapes needed from whatever storage system they're using.

[dmourati]

Seriously doubt Amazon is using tape.

[atYevP]

No one (outside Amazon) truly knows what Glacier is on, likely it is a combination, and tape may play a role, that's why it's relatively inexpensive to house the data, but the costs to get it back are very high and are for "emergency, everything else has failed" situations.

[dmourati]

Asked what IT equipment Glacier uses, Amazon told ZDNet it does not run on tape. "Essentially you can see this as a replacement for tape," a company spokesman said via email.

http://www.zdnet.com/amazon-launches-glacier-cloud-storage-h...

See also: http://en.wikipedia.org/wiki/Amazon_Glacier#Storage