FTA: "If one of the original data shards is unavailable, it can be re-computed from the other 16 original shards, plus one of the parity shards"
So you would have to read 17x the data to recreate it. Given disk latency, network bandwidth, etc. I'm guessing it'll take quite a while to recreate a 6TB HDD if it fails.
The drive operations (including waiting for the head to seek, etc) could take place in parallel. There's also the chance the data needed was in cache. So it might not be horribly bad.
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...
Actually, 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).
So you would have to read 17x the data to recreate it. Given disk latency, network bandwidth, etc. I'm guessing it'll take quite a while to recreate a 6TB HDD if it fails.