Reporting size/free space

[npelov]

Describe the feature would like to see added to OpenZFS

zpool reports free total size and free space for raidz1 based on total disks, not actual usable space. That's different in mirrors. Mirros report - usable space (the copy is not included ). That seems like inconsistency. Shouldn't it be the same for raidz - on the top level (not individual drives) only non-parity space should be reported.

How will this feature improve OpenZFS?

There can be many datasets, especially with docker, lxc and other software that uses zfs. zpool provides faster overview of the pool.
I know zpool reports raw data and it doesn't really translate into zfs space, but it really gives good overview of what's going on with the pool.
a mirror looks like:
zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
archive 3.44T 176G 3.27T - - 1% 5% 1.00x ONLINE -

zfs list archive storage rpool
NAME USED AVAIL REFER MOUNTPOINT
archive 176G 3.16T 96K /mnt/archive

so zpool gives me enough info roughly how much space I have used and is left. Yes, free zpool space doesn't translate to usable space, but still usable info.

zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
storage 29.3T 7.73T 21.6T - - 0% 26% 1.00x ONLINE -

zfs list archive storage rpool
NAME USED AVAIL REFER MOUNTPOINT
storage 5.62T 15.4T 104K /mnt/storage

with raidz1 I have no idea how much space I have. I need to calculate 21.6* (3/4) = 16.2 which is good enough estimation even though actual usable space is 15.4

Additional context

I know that parity is spread over all the disks which probably complicates things. I don't know if subtracting one disk is enough to show the data size only without parity. If it's hard to achieve, then so be it.

alternative would be to get the top level datasets and list them with zfs:

zfs list $(zpool list |tail -n +2|cut -d ' ' -f 1)

but this lacks other pool info like dedup, fragmentation

[amotin]

The reason it is so complicated is that it is really so complicated. ;) From ZFS space accounting perspective, mirror is equivalent of a single disk. And it makes sense, since otherwise attaching and detaching disks for mirrors would be as complicated as RAIDZ expansion, added only lately and still having issues, while opposite operation is still impossible. RAIDZ on the other side has to expose the raw space, since space required for each write heavily depends on a size of that write, and it is calculated dynamically, requiring ZFS space accounting to work in raw space terms there. Each RAIDZ vdev has a factor, supposed to forecast how much space will be required to write some average chunk of data (IIRC it is 128KB). It is used to estimate free space for purposes of zfs list etc. It is not perfect, but that is the best we have other than the raw space reported by zpool list. I think we could add another parameter to zpool list to expose expected available space without parity, but it would not be very reliable if the blocks used are different from the 128KB.

[npelov]

well if it's hard to implement then it's not worth the effort. it can easily be achieved by a script. Thanks for the answer