4 ms·
We're talking about 102TB of data (6TB x 17), so a cache won't dent this figure too much (especially, given that each of those disks is one of 45 drives in the
by ajays 12y ago
We're talking about 102TB of data (6TB x 17), so a cache won't dent this figure too much (especially, given that each of those disks is one of 45 drives in the pod, which means the cache is shared across all of them). Then, each of the drives will also be serving files (or storing them), which means disk heads will be seeking around all over the place while rebuilding the failed drive...
- Dylan16807 12y agoActually, it shouldn't take particularly long. The key is to distribute. Sending 102TB of data to the pod that's rebuilding would take forever, this is true. Instead you have each peer pod be responsible for 1/17th of the parity calculations. 1. 17 pods each read 17 megabytes and sends them across the network. 2. Pod A gets all 17 of megabyte 1. Pod B gets all 17 of megabyte 2. etc. 3. Each pod calculates their megabyte of the replacement drive and send it off. 4. Repeat until 6TB have been processed. So this way each pod reads 6TB from disk, sends 6TB across the network, receives 6TB across the network, and calculates one nth of the data for the replacement drive. It scales perfectly. It's no slower than doing a direct copy over the network. Just make sure your switch can handle the traffic (which it already has to handle for filling the vault in the first place).