I have a pool made of 3 way mirrored vdevs. So without any metadata redundancy or extra copies configured, there's already multiple copies of all metadata.
The pool has ordinary metadata and dedup tables on a fast special vdev (early migrated to 12-BETA for that, because I dont need much else right now!). So there's a lot of metadata. So the zfs property metadata_redundancy = all/most" is really seems likely to create a lot of write amplification, because every metadata now gets extra copies, with all their inherent extra writes when they update.
I can't help thinking this is a classic payoff of security vs speed. But also, isn't the multiple copies of metadata via device redundancy, likely to be enough?
Put another way, is there a rule of thumb, that will tell me if I have enough redundancy at device level, that I don't need to add redundancy at metadata block copies level as well, and speed up my pool that way?
The pool has ordinary metadata and dedup tables on a fast special vdev (early migrated to 12-BETA for that, because I dont need much else right now!). So there's a lot of metadata. So the zfs property metadata_redundancy = all/most" is really seems likely to create a lot of write amplification, because every metadata now gets extra copies, with all their inherent extra writes when they update.
I can't help thinking this is a classic payoff of security vs speed. But also, isn't the multiple copies of metadata via device redundancy, likely to be enough?
Put another way, is there a rule of thumb, that will tell me if I have enough redundancy at device level, that I don't need to add redundancy at metadata block copies level as well, and speed up my pool that way?
