| ▲ | d1sxeyes 19 hours ago |
| At least three copies, so you can recover based on consensus. |
|
| ▲ | Dylan16807 19 hours ago | parent | next [-] |
| If your pieces of important data are very tiny, that's probably your best option. If they're hundreds of bytes or more, then two copies plus two hashes will do a better job. |
| |
| ▲ | d1sxeyes 14 hours ago | parent | next [-] | | Ah, true! You just restore the one that matches its hash. Elegant. | |
| ▲ | rixed 10 hours ago | parent | prev [-] | | A single hash should be enough. | | |
| ▲ | Dylan16807 7 hours ago | parent [-] | | Yes, but what's easier depends on layout. "Consensus" makes me think of multiple entire nodes, and in that situation you can have a nice symmetry by making each node store one copy and one small hash. If you're doing something that's more centralized then one hash might be simpler, but if you're centralized then you should probably use your own error correction codes instead of having multiple copies. |
|
|
|
| ▲ | qznc 10 hours ago | parent | prev | next [-] |
| In many cases the system is perfectly safe when it shuts off. Two is enough for that. |
|
| ▲ | pizza 15 hours ago | parent | prev [-] |
| “never go to sea with two chronometers, take one or three” |
| |
| ▲ | DennisP 10 hours ago | parent [-] | | Seems like chronometers would be a case where two are better than one, because the mistakes are analog. If they don't exactly agree, just take the average. You'll have more error than if you were lucky enough to take the better chronometer, but less than if you had taken only the worse one. Minimizing the worst case is probably the best way to stay off the rocks. |
|