arcstat: Fix integer division with python3

[Kayvlim]

Motivation and Context

The arcstat script requests compatibility with python2 and python3.

When using python2, int/int yields an int and calculations are correct.

PEP 238 modified this behavior in python3: int/int yields a float, and results in erroneous output when running under options like arcstat -a 3.
"Erroneous output" includes cases where hits + miss < reads, or hit% is 1.0K instead of 100, or hit%=99 and 0 misses.

Description

This PR replaces instances of / with //, yielding the expected result in both versions of Python.

How Has This Been Tested?

Since this a utility script, it was tested on my machine by running the utility and verifying that its results make sense.
I also inserted debug prints to peek the internal values, but removed them on the commit.

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)
• 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.

[ghost]

Making this behave consistently with both Python 2 and 3 will be good, but not all of these values need to be integers. There's a reasonable justification that you can't have half a hit or read half a byte, but half a percent should be perfectly valid.

prettynum() also divides by the scale, and has an explicit format string for floating point values. It seems like whether all integers or some floating point values are preferred, that function needs to be adjusted one way or another as well.

[ghost]

To clarify, prettynum() looks like it is likely a source of errors, and restoring integer division may merely be working around it.

[Kayvlim]

@freqlabs

Making this behave consistently with both Python 2 and 3 will be good, but not all of these values need to be integers. There's a reasonable justification that you can't have half a hit or read half a byte, but half a percent should be perfectly valid.

I agree with you that not all of these values need to be integers. In particular, I really don't like to write hit%=100 and miss=0 when there are 1000 hits and 1 miss.

The idea for this PR was only to fix the wrong values when running under python3 compared to what it writes under python2; under python2 it does not (and will not, as I will detail below) write half a percent either.

prettynum() also divides by the scale, and has an explicit format string for floating point values. It seems like whether all integers or some floating point values are preferred, that function needs to be adjusted one way or another as well.

What you are requesting is a bit of an overhaul - one I agree with but can't write anytime soon - because prettynum() isn't expecting floating point values for percentages. There's an explicit instruction in line 249 to turn any number between 0 and 1 into 0 (so there will never be half a percent), and there's a check in line 256 for the special case where the number isn't divided by the scale, which is the case for percentages. I will need to understand what was the rationale behind these lines before changing them, but they certainly need to go.

I considered printing "miss: <1" and "hit%: >99" for these cases, but print_values() expects numbers only, as does prettynum(), so I can't format it this way. One of my ideas for the future includes giving each column its own formatter.

To clarify, prettynum() looks like it is likely a source of errors

Yep!

and restoring integer division may merely be working around it.

The numbers seem to be correct (to +/- 1 unit) after restoring integer division. We simply can do better in how we present them.

I'd rather fix this immediate python3 issue in this PR and open an issue for the other changes I intend to make before I take the time to write the code. Is this acceptable?

[ghost]

Sure, this is ok for now.