gpart show:
The output is the logical starting block, the partition size in blocks, the partition index number, partition type and human readable size.
Are you asking why zpool size property is not the same as the partition size?
Example from my single disk, single pool system. Note that gpart show has size of
484200448 blocks (gpart sized blocks) and human readable of 231G.
zpool list shows size of 230G and zpool get -p size shows 246960619520 bytes which converting to G is 230G.
root@FBSDNUC:~ # gpart show
=> 40 488397088 ada0 GPT (233G)
40 1024 1 freebsd-boot [bootme] (512K)
1064 984 - free - (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 484200448 3 freebsd-zfs (231G)
488396800 328 - free - (164K)
root@FBSDNUC:~ # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 230G 65.3G 165G - - 51% 28% 1.00x ONLINE -
zpool get -p size
NAME PROPERTY VALUE SOURCE
zroot size 246960619520 -
Your zpool get -p size of 506806140928 divide out and you wind up with 472G.
A filesystem size (I'm using filesystem to also mean zpool) is never (almost never?) going to be the exact size of a partition because of the metadata needed to define the filesystem. Larger partition for larger filesystem means more metadata so more variance between filesystem useable space and raw partition size.
Please show the output of "zpool show" and compare the human readable size.