Comment by rckclmbr | Hacker News Reader

Comment by rckclmbr | Hacker News Reader

Parent Full thread

1. Each node is paired with nodes that are "alike", and bandwidth is considered. You should only be paired with other nodes that have bandwidth similar to you.

2. Restoring backups takes a while. It's just the way it is. But the client should be smart enough to get prioritized data first -- if you need to open a picture, it should fetch that first, so you can open it right away.

3. Files are broken apart and stored in chunks, so "growing size of files" is irrelevant.

4. The probability of your data being lost doesn't increase over time. The node is constantly checking the status of your backups. If a chunk is missing over a long period of time, it will back it up again. Redundancy is only part of the solution -- some missing chunks are recoverable through erasure encoding (like in the article you mentioned). Your node backs up to hundreds of other nodes, reducing risk of failure. Think of having 200 drives in an array instead of 7.

5. The article is somewhat FUD. Making projections for 2019 based on hardware speed where we're at now? Many embedded devices are already replacing ARM processors with dual core intel. As data sizes increase, our processing power will also increase.

1. That sounds like a good idea. "Should" and "like" are interesting terms to consider.

2. Restoring backups should not take over two months. That's just not the way it should be.

3. I was talking about using up all of your allocated 1TB, not the size of individual files.

4. I suck at math and can't wrap my head around erasure codes. But think of hundreds of nodes in recovery mode: peak i/o load, bandwidth pegging, resulting in poor performance, higher heat, more likely URE failure. Ever use a cloud server where the neighbors are using too much i/o? That's what will happen to you when your device is pegged by serving file chunks to neighbors. Even with really good load-balancing you have to eventually choose between lower availability or swamping a node.

5. The article is based on UREs not increasing with the size of disks, leading naturally to more errors sooner. As capacity increases and URE stays stagnant, the problem gets worse. The projection will change if UREs get less likely, but there's no sign that will happen in the near future.

3. I think he was referring to aggregate file size (total amount stored) not a single file. If that's the case, his point still stands.

4. He was probably saying that, as the average age of the nodes in the network goes up, the chance of them failing goes up. Also, the duplication you say (hundreds of copies) is in direct opposition to usable space (hundreds of copies means you can only use 1/100 of the space on your node. Because of this, I don't think your files will ever be duplicated on the order of "hundreds", probably less than 10. Also, it's important to keep clear: My node will backup to hundreds of other nodes, but each individual file fragment will only be duplicated to 3 (or whatever) nodes. That smaller number is the important one that keeps getting discussed.

There won't be hundreds of copies. A device may back up data to hundreds of other devices in total, though.

Space Monkey data will be resilient to considerably more than 3 nodes failing.

Hundreds of devices storing small files on your one hard drive could be more iops than the device can handle. Does Space Monkey account for other users potentially killing the performance of a single device?

Reply on news.ycombinator.com