Yes, this is a reasonably common strategy. It's how Cassandra's batch and group commit modes work, and Postgres has a similar option. Hopefully NATS will implement something similar eventually.
The Samsung consumer drives definitely don't do well under sustained high write workloads. The SLC cache fills up after a while, and write speeds drop drastically. The They also have some variety of internal head-of-line blocking type issue, where read latency goes way up when the writes saturate. I can't say I've ever seen 1s latency out of them, though.
Consumer drives can definitely have some quirks. The 2TB 960 Pro also just had weird write latency, even under relatively moderate load. Like 2-4ms instead of <1ms. It didn't really get much worse with extra load and concurrency, except that if there's writes enqueued the reads end up waiting behind them for some reason and also seeing the latency penalty.
They can also be weird behind RAID controllers, though I'm not sure if JBOD counts there. For whatever reason, the 860 EVO line wouldn't pass TRIM through the SAS RAID controller, but the 860 PRO would.
Yeah, even in a case like this where they turned out to be right, it might be one of those "predicted 15 out of the last 2 recessions" sorts of things.
Wouldn't have necessarily had to be nearly as bad as IE6 for security, either. Just lock the special browser to facebook.com only, or even just the ads API, and there's not a lot of room for exploit.
It's a bit hard when the temperature deltas are so small, though. It probably works well if you're pre-heating air before the main heat source in a very cold region, but otherwise you'd need to use some sort of heat pump to get it to move around.
I haven't dug too deeply, but it's unclear whether anything but the Asrock Rack boards have full validated ECC implementations for Ryzen (vs just using the memory but ignoring ECC), and I think that may depend some on which Ryzen CPU is used (maybe PRO-only). I'd love a source of better info there, though.
You're right though - since the client's doing the work and they have a lot of redundancy/diversity in the storage it's not as big of a deal for them as it would be for us. I'd be a bit wary because the client-only verification does mean that there's no verification-with-ECC step in the entire chain, but I'm not sure that's significantly worse in terms of actual risk.
Pretty far. Since we cram so many drives into each server, our total server count is actually relatively low for the amount of storage we have. I'm not sure exactly how many units you need to amortize the design costs across to make it worth it for a custom ODM design, but I suspect it's in the tens of thousands.
It definitely doesn't write it to disk first. It's basically a pipe() under the hood, but exposed as a file descriptor. Downside is that seeking doesn't work, but that shouldn't affect your case.
Disclaimer - Backblaze employee here, but just speaking for myself:
It was.. sort of cheaper. They didn't actually build the servers, and as described the server wouldn't work (onboard SATA didn't support port multipliers, lack of ECC would probably cause problems in practice, bit hand-wavey on power/space/network/manpower costs, etc). The goal of the article was to get other people to build cheap storage and put it up for rent on their network. They do have some amount of storage space available for very cheap on the network now, but personally I suspect it's people who figured "what the heck, I'll give it a try!" as opposed to people actually building storage servers and making a profit renting them out.
I was honestly pretty disappointed - I'd hoped they'd found a cheap motherboard with ECC and support for port multipliers, but nope.
Hi! Backblaze employee who did some of the LB stuff here. It's relatively standard/straightforward. There's a L4 load balancing layer using IPVS and ECMP-via-BGP, then a custom application that does the actual proxying/forwarding to the appropriate vault.
The US was too little and too late with testing for contact tracing to work. It might become possible again if the number of cases gets low enough, though.
The exact numbers? Of course not. Especially early on, they were suppressing information in addition to just not having complete information themselves. The cat's out of the bag at this point though, with WHO observers and foreign reporters on the ground. Even if there's some fudging and incompleteness, the overall trajectory of the infection curve is likely about right.
Probably a lot of the other way around as well. Google employees likely use Chrome and Docs/Sheets heavily, so they get a rapid high-quality feedback loop with any bugs or performance issues affecting the Chrome devs and people around them.
"prone to" is putting it mildly. ICMP echo requests tend to be processed by the often relatively anemic control plane CPU rather than ASICS and are at the bottom of the heap in terms priority. If you send a router 1MB of ICMP echo requests, it's virtually guaranteed to drop some or even most of them.
In addition to the SATA port multipliers, they'd need actual SATA PCIe cards. Basically nobody makes a motherboard with onboard SATA that supports port multipliers.
That's the price being paid for the storage, but is it actually covering the cost of providing that storage? Or is it just 100-300 people who thought "Huh, neat, I'll toss a host online and see how it goes" ? I'd lean towards the latter and assume those storage costs are heavily subsidized by a few people satisfying curiosity.
Even if it had slots for the splitter cable, Intel and AMD onboard SATA explicitly doesn't support port multipliers as far as I know.
You can buy PCIE SAS cards that do for relatively cheap, but then you have to find board with enough PCIe slots. Easy enough on the "gamer" boards but if you want ECC (and you probably do, for storage) and IPMI (you probably do, if you have more than a few dozen servers) your options get much more limited. Other than 1 or 2 Asrock Rack boards, you pretty much have to move into Epyc 7000-series or Xeon Silver or above. Often dual-socket on the Xeons to get a board with lots of PCIe.
In theory something like an Epyc 3000-series with lots of PCIe or onboard SATA that supports port multipliers would work great, but I don't think anyone actually makes that.
The trick is this: the chances that a specific fund will do well that long via luck are very low, but the chances that there exists a fund among all that exist that has done well via luck are quite high.