24.10 RC2 Raidz expansion caused miscalculated available storage

TrueNAS General
, ,
89

Well. The actual host pool only has 4T available[1]… heh, so it would be bad :wink:

Meanwhile, as I mentioned before, this is the relevant quote from the relevant bug

/*
 * Compute the raidz-deflation ratio.  Note, we hard-code 128k (1 << 17)
 * because it is the "typical" blocksize.  Even though SPA_MAXBLOCKSIZE
 * changed, this algorithm can not change, otherwise it would inconsistently
 * account for existing bp's.  We also hard-code txg 0 for the same reason
 * since expanded RAIDZ vdevs can use a different asize for different birth
 * txg's.
 */
static void
vdev_set_deflate_ratio(vdev_t *vd)
{
        if (vd == vd->vdev_top && !vd->vdev_ishole && vd->vdev_ashift != 0) {
                vd->vdev_deflate_ratio = (1 << 17) /
                    (vdev_psize_to_asize_txg(vd, 1 << 17, 0) >>
                    SPA_MINBLOCKSHIFT);
        }
}

So, if the code can’t be changed because its used for BP calculations, it seems like NEW code needs to be added for the ALLOC stats, and the BP calculations need to use the old code.

As mentioned before, I don’t know all the dependencies and requirements at this level of the ZFS code… but this situation is not good for end users.

  1. which would be why I’m currently replacing 8T disks with 22T disks… I can run that test when it finishes… assuming that the expansion works and that isn’t buggy too. ↩︎

3 Likes