How to calculate a new zpool avail capacity?

[TimLand]

1、First debut the space of the parity devices
AVAIL_SIZE = disk_size * ( devices_num - parity_num )

2、Then debut the space of the default spa_slop_shift = 5
AVAIL_SIZE = AVAIL_SIZE * (1 - (1 / 2 ^ 5)) = AVAIL_SIZE * 0.9687

Is this right?

I use the formula to get the result of a new pool avail size was numerical differences with zfs list AVAIL Attributes

Thanks

[rincebrain]

(I don't think "debut" is the word you wanted. It seems like you were using it in place of, perhaps, "calculate".)

Depends on the version, pool layout, and various settings.

RAIDZ available space estimation is always just that - an estimate. If you go write a bunch of ashift-sized records to a raidz or draid vdev, your space is going to vanish far faster than you might expect from just the raw amount of data you logically wrote, for example.

spa_slop_shift (well, the slop space calculation that uses it) is unbounded in older versions of ZFS but bounded to 128GiB (IIRC) in newer versions, so that would also affect what you see.

Then I believe the space that zfs list (or df) will report for pools with raidz vdevs is based on estimating a particular recordsize for all your remaining space, which is just never going to be exactly right. (I would presume the draid calculations have similar oddities, with larger deltas, but don't pretend to know them at the moment.) (This may be inaccurate, but I can't immediately find the way it calculates it, so I'm going to leave it with a warning until someone with a better pointer comes along.)

Finally, not just for raidz, but all your free space is going to be an estimate - since you can't know ahead of time how compressible your metadata for a given file is, for example, depending on what it contains, writing the same file or zfs send stream might have slightly different sizes each time from minor things like a particular metadata block compressing to 12k instead of 16k when it contained the information for the first copy versus the second. (You could, of course, forcibly disable compression everywhere you can to minimize this uncertainty, but then you'd be losing a not-insignificant amount of space savings on metadata...)