zvol_volsize_to_reservation is too pessimistic with small block sizes
While testing the fix for bug 9318, I noticed that the calculated refresevation with ashift=9 and volblocksize=512 was off by about 50% with a 100M volume and off by about 25% with a 1G volume. A modified
data size 1922223125 (1.79G) + metadata size 539492352 (514M)
data size 187717102 (179M) + metadata size 54525952 (52M)
A system without the proposed fix for bug 9318 shows the following on a single disk zpool after fully overwriting the volume.
# zfs get all zones/junk NAME PROPERTY VALUE SOURCE zones/junk type volume - zones/junk creation Thu Jun 13 19:21 2019 - zones/junk used 1.50G - zones/junk available 11.2G - zones/junk referenced 1.02G - zones/junk compressratio 1.00x - zones/junk reservation none default zones/junk volsize 1G local zones/junk volblocksize 512 - zones/junk checksum on default zones/junk compression off default zones/junk readonly off default zones/junk copies 1 default zones/junk refreservation 1.50G local zones/junk primarycache all default zones/junk secondarycache all default zones/junk usedbysnapshots 0 - zones/junk usedbydataset 1.02G - zones/junk usedbychildren 0 - zones/junk usedbyrefreservation 492M - zones/junk logbias latency default zones/junk dedup off default zones/junk mlslabel none default zones/junk sync standard default zones/junk refcompressratio 1.00x - zones/junk written 1.02G - zones/junk logicalused 1.01G - zones/junk logicalreferenced 1.01G - zones/junk snapshot_limit none default zones/junk snapshot_count none default zones/junk redundant_metadata all default
Notice that it reserved about half a gig for metadata but used less than 10% of it.
There are other cases with 512 byte sectors where there's significantly more than 10% extra reserved. With 4k sectors, it is most common for the overshoot to be in the 2-3% range, and pretty much always under 6%.