eadnams

Yeah, bit surprised to find this still here TBH. Even *arr apps do proper color accessibility at this point.

Curious what the improved zfs defaults are, vs what they were.

Exactly. But it does seem to, as though its taking the "free" and "used" and just adding them together to get the total "size". But because the 'used' changes, and the 'free' doesn't always... Though we can grab the more accurate/correct info (see my second comment), to bypass the zfs bug regardless.

Looking through this: https://github.com/openzfs/zfs/discussions/15232 It seems this is a known OpenZFS bug that occurs with expansion. The recommendation is to use "zpool" instead of "zfs" for correct sizes/used/available stats. "zfs" just... gives the wrong numbers. # zpool get free,allocated,size,capacity fast NAME PROPERTY VALUE SOURCE fast free 83.6T - fast allocated 36.5T - fast size 120T - fast capacity 30% -That is all correct. This is not: # zfs get -o value available,used fast VALUE 55.5T 24.3T root@Tower:~# Should I do up a bug report? Its not Unraids fault, but Unraid could use the accurate information instead, to mitigate the zfs bug.

Right, makes sense. It technically is, I suppose. Any idea why it is inaccurate though? I found and removed the reflinked data, have never had dedup enabled, but it still isn't reporting the incorrect amount for "size", and the "size" reported on the dashboard keeps changing on writes zpool get all fast | grep -i clon fast bcloneused 0 - fast bclonesaved 0 - fast bcloneratio 1.00x - fast feature@block_cloning enabled local zfs get -Hp -o value available,used fast 61063925599472 26707992507152 NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT fast 120T 36.5T 83.6T - - 1% 30% 1.00x ONLINE - raidz1-0 120T 36.5T 83.6T - - 1% 30.4% - ONLINE sdh1 20.0T - - - - - - - ONLINE sdn1 20.0T - - - - - - - ONLINE sdg1 20.0T - - - - - - - ONLINE sdk1 20.0T - - - - - - - ONLINE sdl1 20.0T - - - - - - - ONLINE sdi1 20.0T - - - - - - - ONLINE

Not that I can find. I was copying from a root folder outside a dataset, into a dataset. The root is empty now, just has the datasets in it. Mostly just like size reporting in the dashboard to be correct.

Interesting. That may explain it. Is there a way to remove reflinks? I did do a cp operation briefly a while back, which default to reflinks being used. The original files are long gone now. zpool get all fast | grep -i clon fast bcloneused 7.26G - fast bclonesaved 7.26G - fast bcloneratio 2.00x - fast feature@block_cloning active local

It’s interesting, it’s seemingly adding up the used/free numbers to make a total, so the “size” value keeps changing as the pool fills. 😂🤔

zfs get -Hp -o value available,used fast 60496117917184 27283594134544 For comparison: zpool list fast NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT fast 120T 37.2T 82.8T - - 1% 31% 1.00x ONLINE - tower-diagnostics-20251008-1304.zip

Have come across this as well, where a pool in raidz1 of 6 22tb drives is reporting in the web interface Main, a total size of around 80-90 TB (it varies), while zfs correctly reports 6x20T drives as 120T (with 20T used for redundancy, of course). As zfs becomes more integrated, definitely something I hope to see getting more accurate in the future. My other 2 zfs pools seem to be correct though, at least.