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?
Backblaze Storage Pod 5.0
171–180 of 222 posts
Re: Backblaze Storage Pod 5.0
#172Re: Backblaze Storage Pod 5.0
#173Earlier 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…
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
#174Earlier 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.
Re: Backblaze Storage Pod 5.0
#175Interesting, 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…
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
#176Earlier 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.
Re: Backblaze Storage Pod 5.0
#177Earlier 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
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
#178Earlier 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 $.
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
#179Earlier 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…
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
#180Earlier 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).