Live data from Hacker News

Backblaze Storage Pod 5.0

backblaze.com

171–180 of 222 posts

Re: Backblaze Storage Pod 5.0

#171
post #156
post #113

Earlier quoted context omitted.

> You merely state that it's just not state of the art, and to come work at dropbox. That's about all I can do. However... > This is what I mean by being disingenuous. I'm don't think disingenuous is what I'm being. Maybe I'm not being as forthcoming as you'd like. Maybe my comment wasn't useful without details I'm not providing. But I'm not lying or misrepresenting anything. So let me try to be helpful without using…

up to an order of magnitude more 5x the density so half an order of magnitude, which is much more believable?

Nope, that was just for this example; custom enclosures and larger disks can push quite a bit higher than this.

Re: Backblaze Storage Pod 5.0

#173
post #113

Earlier quoted context omitted.

> You merely state that it's just not state of the art, and to come work at dropbox. That's about all I can do. However... > This is what I mean by being disingenuous. I'm don't think disingenuous is what I'm being. Maybe I'm not being as forthcoming as you'd like. Maybe my comment wasn't useful without details I'm not providing. But I'm not lying or misrepresenting anything. So let me try to be helpful without using…

Interesting and thanks for the enlightening comments. I proposed similar things to a few people esp the partnership with hardware development, working around faulty (cheap) stuff, custom firmware, and kernel I/O modifications. I expected each of these in a high-end solution. My architecture didn't have an IP stack at all: guards or front-end acted as I.P. gateway while internally using much simpler protocol that stil…

Wow, very cool!

So, candidate for offloading that's really commonly considered is "scrubbing". Essentially, protecting against passive bit flips by checking your data against your own checksums.

If you have some N TB of data under management, it's really expensive to be striping these large serial reads all the way to an application's userland. So finding ways to keep these as low-priority "background" reads (that always yield to interactive reads) in the scheduling sense that a.) notify the daemon in userland if they fail and b.) without requiring that daemon to be in the data plane, is high-reward. Ideally, the daemon can stay in the control plane so it can manage/report accounting on scrub scheduling and time since last-scrub per disk region, or whatever.

You can offload it to a kernel module to avoid `copy_to_user` (if you can't DMA) and/or context switching. Or even offload it to hardware--some custom host adapter, possibly, using custom ATA/SCSI commands to control it and query it. (and the `sg` driver).

Re: Backblaze Storage Pod 5.0

#174
post #73

Earlier quoted context omitted.

i might be wrong, but i'm fairly certain you have rights that you need to explicitly give up in the form of a license in order for it to be "free"

It's a list of commodity parts and some drawings. If you use this information to build your own pod, who would know and who would care? If you start selling them as your own product, maybe that would be an issue.

I was wondering about this too. Lists of commodity parts might be treated like recipes, which are not subject to copyright per http://www.copyright.gov/fls/fl122.html, but the drawings are a different matter.

Re: Backblaze Storage Pod 5.0

#175
post #95

Interesting, with this information and some idea of what they pay for electricity +support staff/drive replacements/maintenance you could probably figure out their break-even mark. Their cost for the pod (which they say includes labor) comes out to 0.044/GB. The cost of redundancy is 3/20 drives, which would place the cost to 0.0517/GB of data. They are planning to charge 0.005/GB on the B2 service this is made for.…

One thing to keep in mind is that Backblaze keeps 1.15 copies of your data, while Amazon S3 and the like keep multiple full geographically redundant copies of your data. For example Microsoft Azure Cloud Storage keeps 3 to 6 copies of your data, depending on the tier, [1] when you compare that to the 1.15 copies in Backblaze B2 you start to understand where the pricing difference comes from. For most use cases this d…

full geographically redundant copies of your data

In the case of Amazon, I wouldn't be so certain that they're geographically redundant copies. I raised this issue on HN a few months ago and someone replied that within an availability zone the data is "a bunch of (datacenters) that are close to each other". https://news.ycombinator.com/item?id=10231677

I like how for GRS Microsoft specifically says "a second datacenter hundreds of miles away". I have yet to find such clear statements from Amazon.

Re: Backblaze Storage Pod 5.0

#176
post #27

Earlier quoted context omitted.

Good question! As part of the process for developing these we spend months and months using AGILE/SCRUM to iterate and come up with a "final answer" (though we're constantly still iterating). So it's not so much that we gain anything from writing the posts, the posts are more of a culmination of months of effort. We do end up talking about the pods more closely when we're writing the posts and as part of that some mi…

Can you guys enable "non attached" external disk backups? Put a cap on the size or make it a different tier.

We're sort of doing that with B2, read more about it: www.backblaze.com/b2 :D

Re: Backblaze Storage Pod 5.0

#177
post #176

Earlier quoted context omitted.

Can you guys enable "non attached" external disk backups? Put a cap on the size or make it a different tier.

We're sort of doing that with B2, read more about it: www.backblaze.com/b2 :D

Looks nice!

Does it got any kind of integration with stuff you've uploaded through the regular Backblaze app? (e.g. moving stuff over to B2 once it has been uploaded as a regular BB backup).

Re: Backblaze Storage Pod 5.0

#178
post #170
post #151

Earlier quoted context omitted.

So you are using SMR drives. Wow, good luck with that. All the flash front-end caching in the world won't improve the miserable performance of those drives. I guess that's the only way to justify moving out of AWS? I'd really like to see some usage stats on your SMR clusters because so far the universal verdict is that they're terrible for anything other than WORM.

Host Managed (or Host Aware) SMR disks are fine. You need to do your own zone management using ZAC/ZBC, and throw out your filesystem. The disks all have a conventional section near LBA 0 for metadata management (e.g. indices). Usual tradeoff--more work in software, but far less $.

Ah good, now we're talking specifics. Does REPORT ZONES not point to this conventional section always? I cannot wait for a FORMAT ALL ZONES or something command to control the number/amount of conventional sections at the sacrifice of capacity, though it looks like it's not coming.

The power guarantees in the zbc spec (as of r03) seem to not be held by some drives. Writing less than a full zone seems to be a bad idea.

Re: Backblaze Storage Pod 5.0

#179

Earlier quoted context omitted.

One thing to keep in mind is that Backblaze keeps 1.15 copies of your data, while Amazon S3 and the like keep multiple full geographically redundant copies of your data. For example Microsoft Azure Cloud Storage keeps 3 to 6 copies of your data, depending on the tier, [1] when you compare that to the 1.15 copies in Backblaze B2 you start to understand where the pricing difference comes from. For most use cases this d…

full geographically redundant copies of your data In the case of Amazon, I wouldn't be so certain that they're geographically redundant copies. I raised this issue on HN a few months ago and someone replied that within an availability zone the data is "a bunch of (datacenters) that are close to each other". https://news.ycombinator.com/item?id=10231677 I like how for GRS Microsoft specifically says "a second datacent…

Amazon plays games with terms like "durability", meaning that the data exists. That doesn't mean that it is accessible by you or available in its entirety.

Microsoft is definitely more straightforward in its claims. O365 for my org was in Midwest, midatlantic, and southwest, giving us a really good continuity story.

Re: Backblaze Storage Pod 5.0

#180
post #176

Earlier quoted context omitted.

We're sort of doing that with B2, read more about it: www.backblaze.com/b2 :D

Looks nice! Does it got any kind of integration with stuff you've uploaded through the regular Backblaze app? (e.g. moving stuff over to B2 once it has been uploaded as a regular BB backup).

We're treating them like two different products, so no integration yet, but if we see that a sizeable of folks would want to do both or transfer their data over, we might go down that path.
Post reply on HN