Chris A. @caguettaz corrected me on noting that the Datamanagers are close in XOR space to the chunk name, not the PMIDs! So this argument needs revision!! So for now, don’t believe what is written here in my name !
problem: if a big single vault (say 20TB) would have a single PMID in XOR space that is surrounded by several small vaults (eg many 500GB vaults), then if this vault goes offline (either through an attack, or an innocent shutdown). It would/could create an immense churn and flood all neighbouring smaller vaults, as the network seeks to restore redundancy of all chunks stored in that vault. Potentially disrupting the network.
solution: All clients should automatically divide a big storage space provided by a farmer into appropriate ‘optimally sized’ vaults of similar size. Just as file chunks are all 1MB and spread across XOR space; a big storage space should also be divided into similar sized small vaults - magic number alert - of eg 500GB (or less). If a single big storage goes offline, rather then one massive vault going dark, many small vaults go dark across XOR space, each of them neighboured by roughly equally sized other vaults that can easily share among them the burden of taking up the new chunks.
This optimal size should be further investigated and tested. Running a vault has a computational cost on the machine, so pushing the size too low is at the expense of responsiveness. What is important is that all vaults are roughly the same size, at least same order of magnitude. So maybe the network should be able to gauge what the average disk space provided per machine is. Of course to avoid network overhead, it’s pretty clear that this number will be somewhere order 100 GB, and can increase with time as average disk spaces grow with new computers.
I am not arguing to exclude arbitrarily small vaults though! They can contribute, but it should be a minority of vaults that deviate to a relatively small size. So a maximum size, not a minimum size.