Fix bug caused by rounding in vdev_raidz_asize_to_psize

[pcd1193182]

Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.

Motivation and Context

Following @robn 's fix in #17488, I was running some tests with raidz and gang blocks, and ran into a kernel panic. My investigation turned up the following:

When an allocation is happening on a raidz vdev, the number of sectors allocated is rounded up to a multiple of nparity + 1. If this results in the allocation spilling into an extra row, then the corresponding call to vdev_raidz_asize_to_psize will incorrectly assume that parity sectors were allocated for that spilled row, even though no data is stored there.

Description

If we determine that happened, we need to subtract out those extra sectors before performing the rest of the capacity calculation.

How Has This Been Tested?

Manual testing on the system where I found the issue, mathematical analysis with a spreadsheet to verify before/after behavior of the updated formula.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[robn]

I think looks right (with my <24hr-old expert hat on).

[amotin]

The math seems to make sense, but I am not sure I can make sense out of "don't subtract out parity for that row" comment. We are not just not subtracting parity, we ignore it at all.

[pcd1193182]

The math seems to make sense, but I am not sure I can make sense out of "don't subtract out parity for that row" comment. We are not just not subtracting parity, we ignore it at all.

True; the reason we don't subtract parity is the same as the reason we round down overall: because the row can't being used to store data. I can modify the comment to make that clearer.